On 05/07/2018 12:02 PM, Mats Wichmann wrote:
On 05/07/2018 10:16 AM, Jim wrote:
My understanding of VE's, based on some feedback from here, is you
install install the python you want on the system then use it to install
your VE. Then you install what ever you need to the VE. In my case I had
a working VE based on python 3.5 then I received an upgrade to the
python version 3.6 I had installed. After that I had problems with the
3.5 VE that had been working.
yes, this happens.
the default behavior for virtualenv is to make links when creating the
VE, which saves copying things but is vulnerable to breakage if the
Python it's linking to receives major changes. In the case of a
distribution upgrading the Python version, a VE constructed against the
old version will break if the links are version-specific. Looking at
one virtualenv I have, {VEPATH}/lib/python3.6 is full of such symlinks,
e.g.:
lrwxrwxrwx. 1 mats mats 26 Aug 17 2017 re.py ->
/usr/lib64/python3.6/re.py
Virtualenvs are cheap to recreate, so one approach is to just throw away
the old one and make a new one.
My problem is right now the default python3 for my system is also
affected. If I type python3 I will see python version 3.5.2 and I cannot
import tkinter there either.
you can also give virtualenv an option (--always-copy) to cause the
created virtualenv to be more self-contained, at a cost of some space
and tiem.
There are plenty of tools for managing python versions and virtualenv.
The python community changed directions a little bit recently, 'venv' is
now the recommended approach:
https://docs.python.org/3/library/venv.html
That is what I used to setup my VE's.
pyenv can manage different Python versions if you're interested in that.
I am going to see if I can find some log file that would give me a clue
about what happened during the update.
Regards, Jim
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor