Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

But doing it the other way would also make sense

and part of the reason it's all tied to how IvyTaskMixin works is because half of it is in IvyTaskMixin

Speaking of this, <@U066LC126> <@U06A03HV1>: do the changes that are in flight now do anything about isolating the directory for resolution reports?  Presumably by separating it from the artifact directory

I made a change to attempt to do this, but it was messy because it required shared information between ivysettings.xml and the pants invocation of ivy

A quicker, dirtier alternative would be for pants to check a cooperative file lock under the cache directory it's about to use

So it's shared, but at least it's not accidentally concurrent

(This is all so I can put the final touches on Jenkins to get it running stably)

Nick would know best. i'm not actively trying to do anything about the ivy directory, because i know that is an area his work will affect

<@U053H6LQS>: you ok with the arg names on <https://rbcommons.com/s/twitter/r/3509/>?

<@U0D9ZAH98>: re: <https://rbcommons.com/s/twitter/r/3527/> ... if you do the ones in src//python/pants/base/build_file.py src//python/pants/build_graph/build_file_address_mapper.py and src//python/pants/goal/context.py and src//python/pants/option/global_options.py , i'll do the rest

<@U06A03HV1>: I'll be happy to remove the rest :smiley:

<@U053HNE90>: so, the options are a) have pants own ivysettings.xml, or b) add a lock in the ivy cache dir?

I think a) is a reasonable medium term thing to want to do

there are other reasons, eg mutable requires changes to ivysettings.xml in order to work as documented