On 19 August 2017 at 14:03, Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > I would just like to point out that the normal workflow for pyenv [1], > which seems very popular (and which I use), is to do parallel installs > rather than upgrades. The OP didn't actually say "upgrade," so it's > possible they're using a tool like pyenv.
Right, it was the references to sudo-remove, rebooting, and python3 that indicated to me we were talking system wide operations, rather than any of the environment management tools like pew, pyenv, conda, etc. That's why I'm somewhat puzzled, since even a raw "make altinstall" will overwrite an existing installation of that version. The most likely candidate for a system level kinda-sorta parallel installation would be via the distinction between /usr/local/* and /usr/*, and if it's a Debian or Ubuntu system, that would result in the actual system version being able to see components in dist-packages that would be invisible to an unpatched upstream build, each version having its own site-packages directory, but both of them still sharing a common user site-packages directory. Hence my interest in the output of "<path-to-python> -m site" for the affected versions: seeing the default contents of sys.path will likely answer the question of what's going on definitively, rather than having to guess based on incomplete information. I believe the OP's original > questions would also apply to users of pyenv -- i.e. having a simple > way to "copy" installed dependencies from one pyenv install to a new > one. As Wayne noted, generating a requirements.txt file with `pip freeze` and then reinstalling the dependencies essentially *is* that mechanism. If you still have the original wheelhouse cache around, it shouldn't be substantially slower than a plain filesystem copy (since it will just be a matter of unpacking the archived wheel files again, rather than doing any binary builds). For a more literal copy operation, there's "pew cp", but the documentation for that has "this may result in a subtly broken virtual environment" caveats on it for good reasons :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
