https://pantsbuild.org/ logo
Join Slack
Powered by
this is a really silly question — what does the co...
# general
a
this is a really silly question — what does the constraints file provide over just using requirements? i know this is an existing python idiom, but i’m still trying to understand the utility of that. if we wanted versions to be constrained, can’t we just convert all our requirements to == by hand?
h
Not a silly question! See https://www.kennethreitz.org/essays/a-better-pip-workflow for why Pipenv argues that maintaining an exact 
requirements.txt
is not ideal
h
A) You'd have to maintain, by hand, not just the requirements that you care about but those of the transitive closure of dependencies. B) How would you make those decisions? You need a resolver to find a valid combination for you. That is in general an NP-hard problem. Best to leave it to an algorithm than a human...
👍 1
a
Ok, but why not let the resolver do it for you once, then put that in your 
requirements.txt
instead of this new constraints file?
also I believe P = NP but can't prove it yet
also the pipenv site has an SSL error but do not fret i can google
h
Because then you lose the distinction between "things I actually want to depend on, and constraints I impose as a human" vs. "the entire transitive closure of those things, at one specific version each".
For example, say you want to upgrade just one thing. You can't do that in the lockfile, because it may no longer be compatible with the other constraints. You need that original 
requirements.txt
as the source from which a new lockfile can be generated.
a
this makes sense and is really interesting
i'm wondering whether this could be relevant to the dehydrated/ipex idea in #C087V4P1T, which requires a transitive resolve anyway. if we were to enforce in pants that every 
python_binary()
target that we want to generate an ipex for must have an associated lockfile, that would mean we could avoid any need to modify pex to introduce the 
--dehydrated
flag, for example.
i think that's a really interesting idea and will make a comment to that effect in the gdoc
cc @average-vr-56795 ^ this might be a good effort to piggyback off of to avoid having to worry about doing anything special for the resolve part of ipex
a
@aloof-angle-91616 I’m not sure this changes anything there? Fundamentally, there are two relevant files for a target: 
target-specific subset of requirements.txt
(“unresolved deps I care about for this target”) and some kind of lockfile (“resolved transitive deps I will actually use for this target”) This proposal is just that we’ll store a third, non-target-specific file (“resolved superset of deps I may use”) of which target-specific lockfiles are guaranteed to be a subset? Basically just that we’re caching the result of a global resolve to constrain our future resolves, for consistency. Or am I mis-interpreting the proposal?
Assuming that’s right, we’d still need to modify 
pex
both because we’d need a per-target lockfile, and because we’d need something to actually do the fetch on bootstrap. The only thing that would change is that if you built the 
pex
twice in a row, clearing caches in between times, you’re more likely to get the same result, because we’re effectively caching part of the resolve in a new place.
I guess if our constraints file had enough structure in it to note dependency relationships between requirements, it could effectively cache the entire resolve, but that’s a pretty different project.
3 Views
Open in Slack
PreviousNext
Powered by