Pin Your Packages

#1

Post by nvie81 » Wed, Sep 26, 2012, 9:26 AM UTC

Re: Pin Your Packages

#2

Post by zacharyvoase » Wed, Sep 26, 2012, 9:40 AM UTC

A point worth raising: pinning versions of dependencies in your reusable Python packages is a great way of creating conflicts. e.g.: package A requires lxml==2.2.0 and package B requires lxml==2.2.1. Both packages may even work with lxml 2.2.2, but by being overly specific you've created a packaging conflict.

Perhaps a caveat should apply to this article -- it's only applicable to deployments, not to Python packages intended for third-party use.

Re: Pin Your Packages

#3

Post by martey » Wed, Sep 26, 2012, 10:02 AM UTC

zacharyvoase wrote: post #2

A point worth raising: pinning versions of dependencies in your reusable Python packages is a great way of creating conflicts. e.g.: package A requires lxml==2.2.0 and package B requires lxml==2.2.1. Both packages may even work with lxml 2.2.2, but by being overly specific you've created a packaging conflict. Perhaps a caveat should apply to this article -- it's only applicable to deployments, not to Python packages…

The article does state that you should not do version pinning with libraries:

WARNING: don’t pin by default when you’re building libraries! Only use pinning for end products.