Overly restrictive and inconsistent "pinned" package versions #1350
Comments
|
Some general comments/questions about this issue. First, I made some comments on #1351 to hopefully answer why the package pinning is done in the way it is. The following questions occur to me when reading the documentation and then this issue:
In the first case, the user would not care about any versions of any other packages, because the only reason those packages are on the user's system is to use Tax-Calculator. For the second case, the user would create a conda environment for the purpose of using Tax-Calculator (in which case, any and all packages installed in to that environment would be there for express purpose of using/developing Tax-Calculator). For any and all other desired uses of Python, if the user did not like/want the packages that are installed in to the environment for using Tax-Calculator, the user could do as follows: 1. exit the environment by typing In general, a conda environment should be treated as disposable and useful for a particular purpose. The entire goal is to not have to maintain a single Python installation that satisfies many needs: one can have a Python installation for each use case one has for Python. Packages that are useful for that purpose can be added, updated, or removed, as needed.
According to the instructions, one is asked to execute |
|
On Sat, 6 May 2017, T.J. Alumbaugh wrote:
Some general comments/questions about this section. First, I made some
comments on #1351 to hopefully answer why the package pinning is done in the
way it is. The following questions occur to me when reading the
documentation and then this issue:
* Why is it bad/undesirable to downgrade a package in an environment?
This doesn't seem like an important thing to me (if installing a package
requires downgrading some other package), but this issue makes it seem
like it is somehow an important issue. I can see two use cases for
someone uses Python with this project:
1.
the user wants to use Python for the exclusive purpose of using
Tax-Calculator
2.
the user wants to use Python to use Tax-Calculator and do something else
with Python (develop/run other programs, do analysis, etc.)
In the first case, the user would not care about any versions of any other
packages, because the only reason those packages are on the user's system is
to use Tax-Calculator.
For the second case, the user would create a conda environment for the
purpose of using Tax-Calculator (in which case, any and all packages
installed in to that environment would be there for express purpose of
using/developing Tax-Calculator). For any and all other desired uses of
Python, if the user did not like/want the packages that are installed in to
the environment for using Tax-Calculator, the user could do as follows: 1.
exit the environment by typing source deactivate (or deactivate on Windows),
which would take him/her back to the "root' environment. 2. (optionally) the
user could activate/create some other environment for the other uses of
Python he/she had in mind.
In general, a conda environment should be treated as disposable and useful
for a particular purpose. The entire goal is to not have to maintain a
single Python installation that satisfies many needs: one can have a Python
installation for each use case one has for Python. Packages that are useful
for that purpose can be added, updated, or removed, as needed.
* Why it is recommended to execute conda upgrade anaconda in order to the
use Tax-Calculator?
According to the instructions, one is asked to execute conda update anaconda
while inside the taxcalc-dev conda environment. I don't know the impact of
doing such a thing, and I don't know of other Python projects where this is
standard practice. It seems to me to be an odd thing to do.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.[AHvQVWzVXFeE0BT1APFkmau-3ZYRiMKfks5r3RqmgaJpZM4NSgn7.gif]
I suppose it is convenient for the author to require the user to reproduce
the author's environment exactly. That is the theory behind distributing
entire virtual machines. It isn't how I was brought up, however. We were
taught to take pride in writing standard and portable code.
I believe the reason we have no users in the executive branch is the
impracticality of obtaining sufficient timely permissions to install the
calculator. If each revision of the Python source code requires the
installation of various Windows executables, permission must typically be
obtained for those executables. Permission is not easily obtained, and
permission for downgrades is particularly difficult.
dan feenberg
|
I think this might be a voodoo trick that kind of sort of seemed to fix common installation problems in the early days of the project. It is probably out of context now if it ever did truly work. |
|
If we move to |
This afternoon I tried to follow the taxcalc package installation instructions in the user documentation. I did this by creating a new user account on my Mac (which had the Apple version of Python and nothing from Continuum Analytics) and following the installation instructions.
I had no problem installing the offered Anaconda Python 2.7 distribution, which is the 4.3.1 version.
That version of Anaconda came with all the packages used by Tax-Calculator except for the
mockpackage, which is not used in Tax-Calculator calculations, but is used in one of the thee-hundred some unit tests. Among those packages included in Anaconda2 version 4.3.1 are the three packages that have "pinned" versions in theenvironment.ymlfile (which sets the development environment). But those three packages have newer versions in 4.3.1 than in theenvironment.ymlfile. Also, theconda.recipie/meta.yaml(which specifies package versions for the taxcalc package) has "pinned" versions that differ from those in theenvironment.ymlfile. Here is a summary of the the three different sets of "pinned" package versions.But, at least on a Mac, the Tax-Calculator works just fine with the more recent versions of these three packages. After downloading a zip file containing the Tax-Calculator code at the tip of the master branch, bringing to the new tcuser account a copy of the
puf.csvfile, and conda installing themockpackage, I passed all 305 unit tests.So, this experiment seems to prove (at least on a Mac) that the Tax-Calculator will work just fine when using the newest versions of
numpyandpandasandbokeh. Given this, why shouldn't all the=and<=symbols in theenvironment.ymlandconda.recipie/meta.yamlfiles be converted to>=symbols?Unless I get a cogent reason for not making these changes soon, I'm going to prepare a pull request that makes those symbol changes. These changes are essential otherwise the users who download the taxcalc package after installing Anaconda are going to be subjected to a whole set of DOWNGRADE messages when doing the conda install of taxcalc. Here is what I got before I installed the
mockpackage:I have no idea why the anaconda change from 4.3.1 to
customis considered an UPDATE when 4.3.1 is the latest offering on the Continuum Analytics download page.The Tax-Calculator code runs just fine without these DOWNGRADES. So, why should the taxcalc package require these downgrades?
It seems to me there needs to be a careful rethink of
environment.ymlandconda.recipie/meta.yamlfile contents.@MattHJensen @feenberg @zrisher @salimfurth @PeterDSteinberg @brittainhard
The text was updated successfully, but these errors were encountered: