This is some admittedly vague onboarding feedback....
# general
c
This is some admittedly vague onboarding feedback. I'm trying to get pants working with an existing repo that has a tangled
requirements.txt
file that is installed in a managed environment with some pre-existing packages that ought to be treated as constraints but are not yet. It is fair to see that this at best accidentally works and the dependencies are messy. Pants/pex keeps telling me -- correctly! -- variants of "this doesn't work! neither does that! these dependencies are incompatible you fool!", This is good in the sense that part of the reason pants is attractive is to have dependencies that more than accidentally resolve, but it is really hard to get to "first light" for this repo where the unit tests run. Right now it would feel nice if there was a
--yolo
flag to have things "work" like they do today.
e
Pex has such a yolo flag (
--ignore-errors
). If you hand Pex your requirements (
-r myreqs.txt
) then, assuming they are a full transitive list, you can pass
--intransitive
. That should effect a successful Pex build. Now, I'm pretty sure Pants doesn't plumb this; so you can't do it today with Pants, but you could try it out to see if I'm lying or not. I'm not actually exactly sure here.
If your requirements aren't a full transitive list, you probably need to ensure you use
--resolver-version pip-legacy-resolver
- because Old Pip was yolo in how it installed deps - it allowed conflicts just fine 😕
c
--ignore-errors
does indeed get
pex
to build a pex instead of complaining about how it won't "work". Although as you said pants doesn't seem to plumb that through.
e
Ok, so, it sounds like you have a path forward if you think it'll be easier to plumb this through Pants to crutch your repo than it will be to fix your repo all at once.
h
Plumbing that through shouldn't be hard? It would be an option on the
python
subsytem, I think?
e
Yeah, I don't think it would be hard ... except I'm almost positive I have a todo to make this work with lock files; so its not clear which portions of Pants will tolerate this knob. If you use resolves, you still may get failures.
(I actually have no clue how you'd make this work with lock files - sort of antithetical)
c
I maybe got past the errors and onto. But after half an hour I accidentally changed the file system :-/
e
What are your interpreter constraints? Also, after narrowing those if needed, you can try 2.16.x and
[python] pip_version = "22.3"
, Newer Pip fixes some perverse back-tracking scenarious.
On the ICs - Pants ships with a default of `>=3.7,<4`which is ridiculous for most scenarious and a massive range to resolve / search / lock.
c
"CPython>=3.7.1,<3.8" (Trying to do get one major python version working first)
e
Ok, yeah, you might need to try the Pip 22.3 option then to bring down that resolve time.
You can try out probably more quickly /easily with:
Copy code
pex3 lock create --style universal --pip-version 22.3 --resolver-version pip-2020-resolver --target-system linux --target-system mac --interpreter-constraint ">=3.7.1,<3.8" --indent 2 --output lock.json -r requirements.txt
That's what Pants runs at any rate. And you get
pex3
via a `pip install pex`along with the
pex
and
pex-tools
console scripts.
c
Thank for your help! I broke some deps that are used in isolation to another resolver and with that +
--pip-version 22.3
lockfile generation finishes(!!!) in 2m19.049s