search

pylint-bot / pylint-unofficial

UNOFFICIAL playground for pylint github migration
0 stars 0 forks source link

Pin dependencies #118

Open pylint-bot opened 10 years ago

pylint-bot commented 10 years ago

Originally reported by: James Broadhead (BitBucket: jamesbroadhead, GitHub: @jamesbroadhead?)

Please pin the dependencies of pylint, so that two developers installing a pinned version of pylint at different times always receive consistent output. http://nvie.com/posts/pin-your-packages/

This has a serious impact on teams who want to use pylint for CI.

eg. Project pins pylint-1.0.0 in requirements.txt (does not list astroid, since it's not a direct dependency) Dev1 installs pylint via pip install -r requirements.txt, gets version X of astroid Later, Dev2 installs pylint via pip install -r requirements.txt, gets version X+1 of astroid Version X+1 detects new error types over X. Rather than a consistent, planned upgrade to astroid-X+1, either Dev2 must manually downgrade and remember not to upgrade by accident, or the whole team + CI must upgrade to the later version as soon as this situation occurs.

With pinned deps, the whole team could note that a new version of astroid was released, and a new version of pylint, pinned to the newer astroid. In a planned manner, they could upgrade tooling and their requirements.txt.

pylint-bot commented 10 years ago

Original comment by Sylvain Thénault (BitBucket: sthenault, GitHub: @sthenault?):

I'm not keen on pinning dependencies. If I release a new bugfix version of astroid, I want it to be installable along with current version of pylint without releasing it.

pylint-bot commented 10 years ago

Original comment by James Broadhead (BitBucket: jamesbroadhead, GitHub: @jamesbroadhead?):

Yes, pinning deps definitely makes maintaining pinned deps makes making releases of two related projects a bit more work.

However, from the perspective of users of a tool for commit hooks and CI, it's absolutely vital that there is the ability to standardise on a version across the team and infrastructure and receive consistent results.

One way to reach a middle-ground would be to pin pylint to a major version of astroid (eg. 1.0.*), and make the commitment that minor versions should only contain bugfixes, not large changes in behaviour or new features