Add support for controlling prerelease resolution. #350
Conversation
jsirois
force-pushed
the
jsirois/issues/28
branch
from
9e060e0 to
0d6e72f
Compare
This change both allows control over whether prereleases are allowed when resolving requirements and changes the default from allowing prereleases to disallowing them - in line with pip behavior. Support includes a pip-alike `--pre` cli option, support for `--pre` in requirements.txt files, and API support for consumers of the pex library, notably pants.
jsirois
force-pushed
the
jsirois/issues/28
branch
from
2eed000 to
c8f9c00
Compare
|
I'm happy to update |
| # `specifiers` field which is a `SpecifierSet`, but we can't be sure we have that. We can be | ||
| # sure though we have the `Requirement.specs` list of `(op, version)` tuples in all versions of | ||
| # setuptools we depend upon (we use `Requirement.specs` elsewhere in the codebase as well). | ||
| # Kill this re-parsing once our lower-bound setuptools dependency give access to |
There was a problem hiding this comment.
if we do indeed bump to 2.x.x or 1.2.x, this might also be a good time to bump the lower setuptools bound too. afaik, it's completely arbitrary now that pants setuptools versions are modernized.
There was a problem hiding this comment.
Agreed. I'll take that up in a follow-up.
| SETUPTOOLS_REQUIREMENT = 'setuptools>=5.7,<31.0' | ||
| PACKAGING_REQUIREMENT = 'packaging>=16.8' | ||
|
|
||
| # NB: We exlude 7.0b1 since it will use `packaging` if present and we install a modern version of |
|
re: version bumps, I'm good with whatever you think is the most reasonable (2.x.x or 1.2.x). imo, the fact that we were resolving pre-release versions is sort of in the gray area of "bug" territory. ostensibly, we shouldn't have been doing that - so correcting that "bug" here and thus aligning with the spirit of the "correct" design for 1.x may be sufficient grounds for excepting this to a 1.2.x release (and explicitly noting the flag to restore the broken behavior) may be fine. I doubt anyone is relying on this behavior in practice - but may be wrong. ultimately, I had always imagined a 2.x would carry a much larger set of breaking changes, but either way not that big of a deal - will let you decide. |
|
Yeah - I have the same sentiment re |
This change both allows control over whether prereleases are allowed
when resolving requirements and changes the default from allowing
prereleases to disallowing them - in line with pip behavior.
Support includes a pip-alike
--precli option, support for--preinrequirements.txt files, and API support for consumers of the pex
library, notably pants.
This closes #28.