[Distutils] Transfering modules

[Ian Hartley]

Hi all,

I'm using PyCharm CE as my development environment, on a macintosh running
mac OS 10.12.3.

Here's a screenshot of what happens when I run python3 -m site.

[image: Inline image 1]

As an explanation - here's the exact processes that I'd run to achieve the
trouble (and how I fixed it).
After installing the current version with a pip3 install in terminal, I
went to the python website, and downloaded the 3.6.2 package, and ran the
installer.  After realizing that my 3.6.1 modules weren't importable by the
3.6.2 version, I attempted to uninstall 3.6.2 using this method:
https://stackoverflow.com/questions/3819449/how-to-uninstall-python-2-7-on-a-mac-os-x-10-6-4/3819829#3819829
This removed 3.6.2 files but somehow was still running 3.6.2 when I booted
'python3' from terminal.
It was at this point when I reached out to you guys.

I then heeded your advice.  I reinstalled 3.6.2, and migrated the modules
from the 'site-packages' of 3.6.1 to 'site-packages' in 3.6.2.  Through
this process I found that 3.6.1 had somehow been installed in a different
disc location than the entire 3.6 build, which contained 3.6.2.  After
migrating the packages to the real 3.6 build containing 3.6.2, I left the
remaining 3.6.1 location on my disc.

Here's what I still see when trying to configure the PyCharm CE interpreter.

[image: Inline image 2]

Everything seems to be working now though.
Thanks again for your help guys - let me know if you have any additional
questions and I'll do my best to furnish an answer.

I'm studying applications of tensorflow in financial prediction models at
the moment.
If any of you have read any academic papers on the topic that stand out,
I'd be delighted if you might send me a link, or a way I could find it!
Additionally, if you happen to know another Python community member who's
researching the same topic, it would be great to get in touch.

Best regards,
Ian


On Fri, Aug 18, 2017 at 10:57 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170819/d9489eee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-08-19 at 12.12.14 PM.png
Type: image/png
Size: 145996 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170819/d9489eee/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-08-19 at 12.21.51 PM.png
Type: image/png
Size: 132912 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170819/d9489eee/attachment-0003.png>