I have a question about exposing artifacts in a multi-project build. Is it possible to make the filename of the exposed artifact dynamic, i.e. set only after execution of the task that generates it? Or does the filename need to be known during the configuration phase? I've been trying to specify the artifact name using a provider but the result is empty. Searching only produces relatively old answers. The context here is that I need to exposed a python package to other sub-projects, but the wheel file specification requires the filename to be very specific and can vary depending on OS/package content/etc. Right now this is the code that works:

// plugin's apply() method

val buildPythonPackage = project.tasks.register("buildPythonPackage", PythonTask::class.java) {
    ...

    it.outputs.file(
        "build/libs/python/${projectConfiguration.name.get()}-${projectConfiguration.version.get()}-py3-none-any.whl"
    )
}

project.artifacts {
    it.add(CONSUMABLE_CONFIGURATION_NAME, buildPythonPackage)
}

I'd like to do something like:

val dynamicPackagePath = packageOutputDir.map { it.asFileTree.matching { it.include("*.whl") }.singleFile }

val buildPythonPackage = project.tasks.register("buildPythonPackage", PythonTask::class.java) {
    ...

    it.outputs.file(dynamicPackagePath)
}

project.artifacts {
    it.add(CONSUMABLE_CONFIGURATION_NAME, buildPythonPackage)
}

But apparently the path provider is resolved already during the configuration phase

You probably need to separate things. How should you be able to define what the tasks outputs are from its execution result? The information is needed before executing the task to do up-to-date checks, caching, fingerprinting, .... Just for configuring the artifact it might work something like that. But surely not for configuring the tasks outputs

Yeah that was also what my logic was telling me, that dynamic definition of the output is basically incompatible with gradle’s task execution optimizations. I wonder though, would it make sense to rather specify the parent directory of the resulting package file as an output instead? Granted, I’m controlling creation and content of that folder in the plugin Or what are the two separate things you have in mind?

Yeah, defining a directory as output is fine. The "two separate things" was a misunderstanding I think. I guess I started with assuming that you want to change the filename that is generated, not determine the output file from what was created.

ok I guess I'll have to try it out and see. Worst case I'll just make it work as it is right now with a pre-computed filename (wheel filename structure is well-defined but there are many variables that add to the end result so I'd prefer reinventing that wheel - pun intended). Thanks!

pun intended, but still a "not" missing 😄

Ahah you’re right, late night writing showing up 😁