Questions about package pinning

[martinholmer]

At the end of the discussion of merged pull request #687, @MattHJensen asked this question:

This is an OK approach only if it is a short-term fix. The versions should ideally be package>=x.y.z not package==x.y.z.

@martinholmer, could you explain why you believe >= is preferable to ==?

Let's call package==x.y.z exact pinning and call package>=x.y.z at-least pinning.

Ideally, the conda.recipe/meta.yaml for a project would contain a list of packages required for the project in which none of the packages were pinning in either way.

Why would we ever introduce at-least pinning for a package?
As far as I can see, there is one and only one reason: the project relies on a feature that was first introduced in the A.B.C version of that package. All package versions before A.B.C do not have the feature required by the project. In this case, it makes sense to use at-least pinning, and so the specification of the package would be package>=A.B.C.

Why would we ever introduce exact pinning for a package?
In my view, there is never a good reason to use exact pinning. This view is based on observation of other projects and on our experience with exact pinning in the Tax-Calculator project. Here are several reasons for why exact pinning is a bad idea:

1. Other projects don't use exact pinning. For example, look at the dependencies list for the pandas package and you will see only at-least pinning. And here is a fragment of the conda.recipe/meta.yaml file in the bokeh repository. Notice the bokeh project depends on numpy but can use any version. In the above list only nodejs and tornado are at-least pinned (and no required packages are exact pinned). The nodejs package is pinned to >=6.10.0 even though the current version of nodejs is 8.6.0. The tornado package is pinned to >=4.3 even though the current version of tornado is 4.5.2.

requirements:
  build:
    - python
    - setuptools
    - nodejs >=6.10.0
    - certifi
    - pycurl
    - packaging
    - six
    - python-dateutil
    - numpy
    - yaml
    - pyyaml
    - jinja2
    - tornado >=4.3

2. Exact pinning hides poor programming practices. When a new version of numpy became available recently, we discovered two mistakes in our Tax-Calculator code --- see PR1470 and PR1473 ---
   that would have never been found if we had been exact pinning to older versions of those packages. Another example in the PolicyBrain project is the generalizations made in PR Adding dynamic CDNs for the widgets #688 after the availability of bokeh 0.12.9 revealed less than general code.

3. Exact pinning prevents a project from benefiting from package improvements. For example, even though it took some time to fix the bugs revealed by the new version of numpy, using the new numpy version (and the pandas version that used it) caused the Tax-Calculator to execute almost twice as fast as when we used the older versions.

4. Exact pinning will eventually prevent package creation for the project. This is the most severe problem with exact pinning and it was experienced by the Tax-Calculator project. In the past, Tax-Calculator used exact pinning and as a result eventually a conda taxcalc package for Python 3.6 could not be built. This was because the versions of numpy and pandas being used by Tax-Calculator were so old that Python 3.6 did not support them. Only after we switched from exact pinning to at-least pinning were we able to build taxcalc packages for Python 3.6. For another, more recent, example of this same problem, look at Tax-Calculator pull request 1587.

@MattHJensen @hdoupe @GoFroggyRun

[hdoupe]

@martinholmer Thanks for posting this. You offer compelling reasons for not pinning a package. Hopefully, after merging PR #688, we will not have to pin to a specific bokeh version.

Further, I think this is another example of a quality teaching or best-practices post. Another one that quickly comes to mind is @talumbau 's post on the requests library and posting data through a user interface to a website. I think it would be useful to have these aggregated in one place as an engineer's blog or something like that. Facebook has one that is fun to check out. These blog posts would be created organically from especially informative comments and threads here. So, the cost wouldn't be much higher than writing the comment itself.

[martinholmer]

@hdoupe said in the discussion of issue #697:

Further, I think this is another example of a quality teaching or best-practices post. Another one that quickly comes to mind is @talumbau 's post on the requests library and posting data through a user interface to a website. I think it would be useful to have these aggregated in one place as an engineer's blog or something like that. Facebook has one that is fun to check out. These blog posts would be created organically from especially informative comments and threads here. So, the cost wouldn't be much higher than writing the comment itself.

I think the blog idea is great. See if @MattHJensen agrees and, if so, discuss with him how the blog should be built and maintained.

[hdoupe]

Thanks for the informative post @martinholmer. PolicyBrain certainly has an exact pinning problem. A review of what is installed on PolicyBrain and what version restrictions are used is definitely in order.

[hdoupe]

Closed #697