python - Am I using virtualenv wrong or is this a limitation of it? -


so used virtualenv define environments number of projects working on. defined virtualenv python being version 3.4. eventually, global python upgraded 3.4.0 3.4.3. proved problem because virtualenv dependent on global binaries (the contents of /lib/python3.4 in virtualenv links global binaries), , these aren't defined minor versions. in other words, when upgrade done, contents of binary folder /usr/lib/python3.4 replaced. because python doesn't install things separately in 3.4.0 , 3.4.3 single folder named /usr/lib/python3.4. since python executable in virtualenv 3.4.0, there compatibility issues 3.4.3 binaries (it fail load ctypes prevented python dependent run). fix i've found downgrade global python installation, feels "dirty". if had 1 project running 3.4.0 , running 3.4.3 ? there no way make them work in parallel on same machine given 1 binary folder can exist 3.4.x installation ?

i'm trying understand if i'm missing obvious here or if common problem virtualenv, given i've heard quite few people complain issues binares when using virtualenv.

in future, there anyway of telling virtualenvwrapper copy binaries rather link them ?

virtualenvs not desiged portable, both across machines or across python versions.

this means upgrading python versions breaks virtualenvs. need recreate them , reinstall inside of (run in virtualenv root):

# save list of had installed pip freeze > freeze.txt  # trash entire virtualenv deactivate rm -rf lib/ bin/ share/ man/ include/ .python pip-selfcheck.json  # create anew virtualenv .  # install libraries had before pip install -r freeze.txt 

Comments

Popular posts from this blog

Spring Boot + JPA + Hibernate: Unable to locate persister -

go - Golang: panic: runtime error: invalid memory address or nil pointer dereference using bufio.Scanner -

c - double free or corruption (fasttop) -