does anyone successfully use pants keeping multipl...
# general
f
does anyone successfully use pants keeping multiple versions of 3rdparty python libraries around? it seemed to kinda work, but when our ci script ran
./pants test lint ::
(roughly) it tried to import both versions of the library and failed.
a
i believe there are two answers to your question, one involving the python pipeline porting effort to the new engine which helps to isolate python code (in progress: https://github.com/pantsbuild/pants/issues/6915), and as for incrementally allowing the action you describe, something like https://github.com/pantsbuild/pants/issues/6902
h
I don’t think the second PR is quite the same thing. I think it’s more targeted around having one version of a tool like MyPy or Pylint, and only running that took over a certain set of files; as opposed to allowing you to install two versions of that tool
👍 2
e
This is a general Pants deficiency not related directly to python. In general, :: will fail for many pants goals against python targets, jvm targets, etc. See here for a way to do 'Continuous Integration': https://www.pantsbuild.org/orgs.html We're working on supporting :: generally, but it's a ways off still.
👍 2
f
interesting. just out of curiosity, is there a summary on the issues with a top-level
::
somewhere? I guess this applies to any glob that touches “sufficiently many” targets to expose whatever issues are being run into?
e
The summary is just that most tasks were written to batch back in the day. Among these, dependency resolves. It's mainly (all I think) surrounding fixing resolves for repos that have no global resolve solution - most don't.
For historical clarity, the repo pants grew up in held a single global resolve solution for ~2 years before split Hadoop deployment cluster versions crept into reality and 1st broke global resolves on the jvm side.