Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter prerelease versions in package iterators by default #28

Closed
wickman opened this issue Dec 2, 2014 · 6 comments · Fixed by #350
Closed

Filter prerelease versions in package iterators by default #28

wickman opened this issue Dec 2, 2014 · 6 comments · Fixed by #350
Assignees
Milestone

Comments

@wickman
Copy link
Contributor

wickman commented Dec 2, 2014

Pip has the --pre flag -- we should allow similar behavior.

@wickman wickman added this to the 1.0 milestone Apr 4, 2015
@wickman wickman modified the milestones: 1.0, 1.1 Jul 7, 2015
@jsirois jsirois mentioned this issue Oct 7, 2015
@jsirois
Copy link
Member

jsirois commented Oct 9, 2015

OK - modern pip does this via packaging which has only been around since 2014. We support setuptools>=2.2,<16 and 2.2 does not use packaging. I have not dug deeper, but I want to take a bit more care if I implement this, so I'm going to drop from the 1.1 release and move to a 1.2 milestone.

@daveFNbuck
Copy link
Contributor

+1, pulling in prerelease versions is probably worse than not supporting old setuptools. The logic is pretty simple, perhaps we could just reimplement it if old setuptools support is a priority.

@jsirois
Copy link
Member

jsirois commented Jan 20, 2017

OK - looking back into this, it looks like the only version of setuptools that depends on packaging is 7.0b1. The 7.0 version doesn't use packaging and the 8.0 version uses it, but it pulls from a vendored version. So one option is to exclude 7.0b1, ie add !=7.0b1 to our requirement string, and then add our own dependency on packaging (16.8) at a top level to pick up packaging.specifiers.SpecifierSet which has the logic we need with a prereleases flag we can toggle.

I'll take a spin at this presently.

@daveFNbuck
Copy link
Contributor

Thanks @jsirois!

@jsirois
Copy link
Member

jsirois commented Jan 23, 2017

This is in and will go out with the 1.2.0 release - likely to be published and consumed by pants in this Friday's 1.3.0.dev8 pants release.

@daveFNbuck
Copy link
Contributor

Thanks again for the quick turnaround on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants