Do not pin dependencies to specific versions#202
Do not pin dependencies to specific versions#202Silviu Tantos (razius) wants to merge 2 commits into
Conversation
Because the packages in `setup.py` are really old and they use exact version, when installing the package into a virtualenv it will end-up downgrading already existing packages. In the Python documentation it is also mentioned that it is not a best practice to use `install_requires` to pin dependencies to specific versions. See also: - snowplow#195 - snowplow#198 - https://packaging.python.org/discussions/install-requires-vs-requirements/#install-requires
|
Looks like Python 3.3 has reached EOL and is no longer supported, should I drop the test for it and update docs? |
|
Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://github.com/snowplow/snowplow/wiki/CLA to learn more and sign. Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks. |
|
I signed it. |
|
Silviu Tantos (@razius) has signed the Software Grant and Corporate Contributor License Agreement |
Ben Fradet (BenFradet)
left a comment
Ben Fradet (BenFradet)
left a comment
There was a problem hiding this comment.
LGTM, I'll let Anton Parkhomenko (@chuwy) have a look
| "greenlet==0.4.10", | ||
| "requests==2.2.1", | ||
| "greenlet>=0.4.10", | ||
| "requests>=2.2.1", |
There was a problem hiding this comment.
I think it would better to put upper bounds to be safe, but feel free to ignore this suggestion. For example Requests uses semver: http://docs.python-requests.org/en/master/dev/philosophy/#semantic-versioning
There is also ~= operator if you prefer it: https://www.python.org/dev/peps/pep-0440/#compatible-release
There was a problem hiding this comment.
Using the ~= will still downgrade if the minor version doesn't match so I'm not sure but an upper bound sounds like a very good idea.
What should the upper bound be? I can bump on our end to latest, try it out and put that as the upper bound.
There was a problem hiding this comment.
For requests I think it's safe to put < 3.0.0 as they are using SemVer - for others I guess it depends what versioning scheme they are using?
There was a problem hiding this comment.
I'm also all for adding upper bounds. Of course we need to update the tracker more often, but last time unbounded dependencies caused a lot of pain as we simply didn't know what deps were used last time.
There was a problem hiding this comment.
+1 for upper bounds
There was a problem hiding this comment.
Silviu Tantos (@razius) If we can get upper bounds on all these, this should be ready for merging.
There was a problem hiding this comment.
Michael Hadam (@mhadam) , I'll try to find some time this weekend.
|
I see this was done in 91da00a. |
I don't see any changes in |
|
Michael Hadam (@mhadam) , wouldn't it be this ? 91da00a#diff-2eeaed663bd0d25b7e608891384b7298R77 |
|
I think what we're aiming for is that So all of these need >= for the versions and proper upper bounds, I think most if not all follow semver. |
|
closing this in favor of #209 |
8 participants
Because the packages in
setup.pyare really old and they use exactversion, when installing the package into a virtualenv it will end-up
downgrading already existing packages.
In the Python documentation it is also mentioned that it is not a best
practice to use
install_requiresto pin dependencies to specific versions.See also: