I am trying to install ZODB on a new machine. I would like to match the same installation I have on another machine (the newest ZODB does not install correctly with easy_install). I have the easy-install.pth from the original that I would like to install on the new machine:
import sys; sys.__plen = len(sys.path)
./zodb3-3.10.0b1-py2.5-win32.egg
./zope.interface-3.8.0-py2.5-win32.egg
./zope.event-3.5.1-py2.5.egg
./zdaemon-2.0.4-py2.5.egg
./zconfig-2.9.0-py2.5.egg
./zc.lockfile-1.0.0-py2.5.egg
./transaction-1.1.1-py2.5.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
Is there a way install these exact files on the new machine? I tried copying the folders onto the new machine, but python does not see the module.
pip supports a manifest or you can use zc.buildout. pip may be the least friction if you are comfortable with easy_install.
I ended up just copying over the .egg folders over to the new machine as well as the easy-install.pth (which I renamed to zodb.pth) and everything worked great. Not perfect, but exactly what I was looking to do.
Related
This question is somewhat similar to the one here, but I cannot make it work.
So suppose that I have a set of packages (say 2) to install and I want to use pipenv. If I do pipenv install on the directory with a suitable Pipfile the installation fails because there is some metadata issue when installing one of the libraries (say libX) contained in install_requirements of one of the packages. It seems that the problem can be fixed by downgrading the version of setuptools to <=58.0.0.
OK. Now, if I first install that version of setuptools<=58.0.0 in the venv and then install my packages, everything works fine. The issue is that the Pipenvfile does not respect the order when installing, so something like
[packages]
setuptools = "<=58.0.0"
pckg1 = {<github path 1>}
pckg2 = {<github path 2>}
is not ensured to work. Also, by default the seed packages added to the venv include setuptools==65.6.3.
So the idea is to be able to restrict the version of setuptools that is used to check the metadata of the libraries in libX, to mimic the above scenario in which setuptools was installed first. Is there a way to do that?
I have tried placing setuptools<=58.0.0 at the top of the requirements.txt that defines the install_requirements of the problematic package, but it does not work.
If have also tried to fix or restrict the version of libX contained in that requirements.txt file but, surprisingly, pipenvdoes not seem to care: a verbose install shows that it keeps downgrading libX well below the restriction - "using cached libX-vX.X.X"- until it uses a version for which the metadata generation fails (why on earth does it do that, even if I call it with pipenv --clear install?).
I am a bit lost about what could be the best solution here. Any help would be very appreciated.
I've seen a couple of fixes for this, but none have worked for me, but I gather that its my virtualenvs that got broken. I just upgraded to 14.04 from 12.04, and now all my pyramid applications no longer work.
When I run ../bin/pserve development.ini, I get the following error:
ImportError: No module named _ctypes
When I run ../bin/python setup.py develop, (also when I try run pshell) I get:
ImportError: No module named _io
I've fixed one project (each pyramid app is in a separate virtualenv) by first removing the old project folder, then reinstalling the virtualenv instance and then copying my scripts back into it. But this is time consuming, and I have several projects.
Is there a quick fix for this?
I've seen removing duplicates of python and simple reinstall of virtualenv, but removing duplicates is not a good option, and the second solution didn't work for me. But maybe I did something wrong there.
I really think that there should be a quick fix for this. Surely reinstalling all virtualenvs cannot be the only solution?
You can simply do
cp /usr/bin/python2 /path/to/my-virtualenv/bin/python2
or
cp /usr/bin/python3 /path/to/my-virtualenv/bin/python3
(Don't need to make a new virtualenv.)
A quick fix that works is to create a new virtualenv and copy its bin/python to the broken virtualenvs. Five simple steps:
mkvirtualenv lero
cd ~/.virtualenvs
for d in */; do cp lero/bin/python $d/bin/python; done
deactivate
rmvirtualenv lero
I've had many questions about Python for which a suggested answer is often "use virtualenv", but I have a (lovingly maintained and perfectly functioning) Python installation that I'm loath to disturb.
I want to be absolutely sure, so I'll ask twice: Does use of virtualenv in any way disturb my "real" Python installation? Using virtualenv does not in any way modify the files or paths in my "real" installation, right?
Virtualenv creates separated Python environment. Python interpreter is linked from one of system-installed that you choose creating virtualenv( --python commandline switch) and, optionally, wheater use or not system site-packages (--system-site-packages).
All packages that you install using virtualenv remains only on virtualenv directory site-packages folder and do not mess system packages.
I have a relatively big project that has many dependencies, and I would like to distribute this project around, but installing these dependencies where a bit of a pain, and takes a very long time (pip install takes quite some time). So I was wondering if it was possible to migrate a whole virtualenv to another machine and have it running.
I tried copying the whole virtualenv, but whenever I try running something, this virtualenv still uses the path of my old machine. For instance when I run
source activate
pserve development.ini
I get
bash: ../bin/pserve: /home/sshum/backend/bin/python: bad interpreter: No such file or directory
This is my old directory. So is there a way to have virtualenv reconfigure this path with a new path?
I tried sed -i 's/sshum/dev1/g' * in the bin directory and it solved that issue. However, I'm getting a different issue now, my guess is that this sed changed something.
I've confirmed that I have libssl-dev installed but when I run python I get:
E: Unable to locate package libssl.so.1.0.0
E: Couldn't find any package by regex 'libssl.so.1.0.0'
But when I run aptitude search libssl and I see:
i A libssl-dev - SSL development libraries, header files and documentation
I also tried virtualenv --relocatable backend but no go.
Export virtualenvironment
from within the virtual environment:
pip freeze > requirements.txt
as example, here is for myproject virtual environment:
once in the new machine & environment, copy the requirements.txt into the new project folder in the new machine and run the terminal command:
sudo pip install -r requirements.txt
then you should have all the packages previously available in the old virtual environment.
When you create a new virtualenv it is configured for the computer it is running on. I even think that it is configured for that specific directory it is created in. So I think you should always create a fresh virtualenv when you move you code. What might work is copying the lib/Pythonx.x/site-packages in your virtualenv directory, but I don't think that is a particularly good solution.
What may be a better solution is using the pip download cache. This will at least speed up the download part of pip install. Have a look at this thread: How do I install from a local cache with pip?
The clean way seems to be with virtualenv --relocatable.
Alternatively, you can do it manually by editing the VIRTUAL_ENV path in bin/activate to reflect the changes. If you choose to do so, you must also edit the first line (#) of bin/pserve which indicates the interpreter path.
Running on MAC os 10.6.8
with postgresSQL installed, as well django - using python2.7
Also installed psycopg2 and dj-database-url using pip in my virtual env
And added these two lines to my setting.py:
import dj_database_url
DATABASES = {'default': dj_database_url.config(default='postgres://localhost')}
Based on instructions for Heroku in:
https://devcenter.heroku.com/articles/django#database_settings
When running:
python manage.py runserver
I am getting this error:
ImportError: dlopen(/Users.... venv/lib/python2.7/site-packages/psycopg2/_psycopg.so, 2): Symbol not found: _PQbackendPID
Referenced from: /Users.... venv/lib/python2.7/site-packages/psycopg2/_psycopg.so
Expected in: dynamic lookup
I kept searching for hours and tried all kind of thing including the advice on:
Mac OS X Lion Psycopg2: Symbol not found: _PQbackendPID
to no avail.
Wonder if anyone had such an issue and had any luck.
I had the same problem. Instead of installing the dependencies as Heroku suggests using
pip install Django psycopg2 dj-database-url
clone whatever repo you're hoping to run in venv, keeping its original settings.py. Then:
source venv/bin/activate
to activate the new environment, cd into your new repo, and python manage.py runserver. Should be set.
Alternatively, you could remake PostGreSQL, and run again, but that's a bit more of a task - it would work for psycopg2, though. As far as I can tell that issue comes from using an 64 or i386 build when you should be using a 32 build - but I'm not sure about this, and the above solution works well to solve the problem and use venv for what you're actually going to be using it for, most likely.
I had the same problem as you guys and I had read many pages and I couldn't find the answer in any of them. Many solution was about installing from source file and don't relate to the virtual environment.
I've found and tested following solution and it solve my problem.
1- Make sure your Postgres is NOT higher than 9.4 version according to psycopg2. Check python version as well. I use Postgres 3.9.9.
2- The problem is behind different version of Python(32/64 bit). It should comply with your operation system's bit architecture which is 64bit. Uninstall all versions of Python and pip from your system. Instruction you can find here but do NOT remove Python2.7 which is Apple-supplied system Python.
3- Install "Mac OS X 64-bit/32-bit" installer from python official website and install it.
After that install pip. Note that you should use the command "python3.5" for using Python version 3.5. You might install virtualenv from the new pip as well.
4- After all that you can go on your virtualenv and type "pip3 install -r requirement.txt" for installing all dependencies on your local machine.
Hope this can help you.