[Distutils] Transfering modules

[Nick Coghlan]

On 19 August 2017 at 14:03, Chris Jerdonek <chris.jerdonek at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia