Closed Olivia5k closed 9 years ago
Ugh, it's pretty annoying to upgrade everything and then have to sort the output from pip frez
into install_requires
and test_require
. I guess it's not really kosher to have the package install test dependencies into the actual package just to soothe developer fuzzy feelings?
@daenney, what do you think?
I tend to not lock package versions in setup.py
too much. So I generally go >= 1.0.0 < 2.0.0a0
for projects that follow SemVer and not worry until tests show that it breaks. Of course if we use a feature that requires a minimal version of a library we should accurately reflect that in setup.py
.
Sounds good to me! I'll try to reflect that in the hax I'm doing right now!
How important is the a0
part? Will the resolver download alphas without that?
As far as pytz goes, don't lock that version. You almost always really want the newest version of pytz anyways because there's no good reason to run on an outdated Olson database except for "I want to deal with timezone problems".
Quoting from here:
To mitigate this risk, do not use the foo >=0.3, <0.4 style declaration, which has a purely numeric upper bound. <0.4 still admits versions 0.4a0, 0.4a1, 0.4b0, 0.4c3, etc. Instead, use an upper bound like <0.4a0, as in foo >=0.3, <0.4a0, when you write your install_requires.
Having < 2.0.0a0
will prevent it from grabbing any 2.0.0 release, including alpha, beta's and rc's.
Roger that on both counts!
@daenney: Merge if looks good! I replicated the different versions, so something that just has 0.x
will just have restriction to <1.0a0
rather than the semver <1.0.0a0
.
Bam!
pytz
has an unresolvable version conflict right now. Let's solve it by updating all dependencies!