I have a virtual environment, that's used by multiple people on multiple machines. I ran into a problem today that a user couldn't import argparse.
The problem ended up being that I am running python2.7.10_2 and he is running 2.7.13. The python in the virtualenv, is mine, so 2.7.10_2. This meant that it was looking for system libraries in the wrong place (/usr/local/Cellar/python/2.7.10_2, instead of 2.7.13/) However, I thought that the point of virtual environments is that all of the libraries are in the venv, and so it doesn't matter what versions of python you actually have installed anywhere.
However, it seems that there is no argparse in venv/lib/site-packages, and so it uses my original PYTHONPATH, which isn't correct for the user.
For other reasons, the virtualenv was originally created with the relocatable flag, so that isn't the problem.
ETA:
The solution I came up with (hideous kludge though it is) Is that I had the user symlink 2.7.13 to 2.7.10_2, so it can find his original libraries.
Related
I'm coming to python from R, where package management is really simple. As I learn python (though a lot of googling), I see recommendations about virtual environments (which I never set up), and conda over pip for package management (I did pip because it seemed easier).
So now I've got a bunch of libraries installed globally, spyder is broken after a routine ubuntu ubdate (this problem, I think, which is solved using conda), and I am contemplating starting from scratch. But I know that lots of other system programs depend on python, so I can't just nuke it and start over like I would with R.
So:
Is my instinct correct? Should I "start fresh" with my python environment?
How do I do this in a way that won't disrupt other processes on my machine?
I know that python 2.7 exists on my machine, and I assume that it does something consequential. I use python 3 for manipulating and analyzing data. I think that this is relevant, but I am not sure how.
I've been going with a basic Python3.4 install that I've been installing many modules into for over the past month but have reached a point where pip is coming up short and I'm going to just install the full Anaconda on my system to go deeper into bokeh-server stuff.
I get a popup during the Windows 64bit installer (Anaconda3-2.3.0-Windows-x86_64.exe) saying
A version of Python 3.4 (64-bit) is already at C:\Python34\ We
recommend that if you want Anaconda registered as your system Python,
you unregister this Python first. If you really know this is what you
want, click OK, otherwise click cancel to continue.
Didn't find much documentation on this subject, and I'm not really sure how to "unregister" that installation of Python apart from uninstalling it entirely from Windows which I imagine would accomplish such a thing. Is this basically telling me to check how my Python Launcher for Windows is setup after the Anaconda installation? I'm completely unfamiliar with this notion of python system registration? Is that just a round about warning about which python version takes precedence on the system path, or which installation holds the file associations?
The solution is simply to uninstall python (for example, run the original python installer and select the uninstall option). The python key in the windows registry will be removed (which is what unregister means in this context).
Here is a link to a script that will unregister a Python installation (if you haven't come across it already). I personally have not dealt with anything like this. It seems like it should work, but you may have to tinker around with some of the paths in the script to get things to work. The links in #nightuser 's post will also probably fix the issue.
Why not just remove your version of Python? You could do a pip freeze > requirements.txt with your current Python and add them to Anaconda, or create an environment with Anaconda using those packages. Anaconda has greatly decreased the amount of time I spend setting things up.
You are getting that prompt because you have another version already installed the safe way to do this is going to the directory of the existing version and running the uninstaller. Once the previous version is completely uninstalled. You can run the installation as normal it should works!
enter image description hereYou have already installed python in your environment, so your system can handle your python code. Anaconda can handle your python code as well. If you install Anaconda and expect use python provided by Anaconda, then your system will confuse about assigning the code job. To avoid this confusion, there is always a path to point out which python you want.
You can ask your OS to find specific python by changing your environment path in windows OS:
By deleting the python path your Python will be invisible. Changing path is more convenient compared with the uninstall.
If you got a python compiling software like Pycharm, things are different. Pycharm may have python3.6 while your system got python 3.5. You need to delete path in those software or uninstall python specified by those software.
Pycharm
Actually, instead of registering the Anaconda as the system python, you can install it first, then specify your Pycharm and system path to the Anaconda python path. Thus, your Pycharm will use python provided by Anaconda and package & virtual environment you need.
I edit this for lots of times because I got Great wall, so I can't close something pop up in my screen(cause it is Blank). And everything is missing if I refresh. This is annoying.
My system path Anaconda3's python36
Add path in Pycharm
Or you can't use these packages and Anacon's virtual Environment
First of all let me state that I am a proponent of generic software (in general ;-). I am no expert on Python, but it seems that the 'virtualenv' utility solves pretty much the same problem 'chroot' can help to solve - bootstrapping a directory tree that can be passed as root, thus effectively protecting the real directory tree, if needed.
Since I am no expert in Python as already mentioned, I wonder - what problem can virtualenv solve that chroot cannot? I mean, can't I just set up a nice fake root tree (possibly using union mounting), chroot into it, and do pip install a package I want in my new environment, and then play around within the bounds of my new environment, running python scripts and what not?
Am I missing something here?
Update:
Can't one install packages/modules locally in whatever application directory, I mean, without root privileges and subsequently without overwriting or adding files to /usr/lib or /usr/local/lib? It appears that this is what virtualenv does, however I think it has to symlink or otherwise provide a python interpreter for each environment one creates, does it not?
bootstrapping a directory tree that can be passed as root
That's not what virtualenv does, except (to some degree) for Python packages. It provides a place where these can be installed without replacing the rest of the filesystem. It also works without root privileges and it's portable as it needs no kernel support, unlike chroot, which (I presume) won't work on Windows.
Can't one install packages/modules locally in whatever application directory
Yes, but virtualenv does one more thing, which is that it disables (by default at least) the system's Python package directories. That means you can test whether your package correctly installs all of its dependencies (you might have forgotten to list one because it's already installed on your system) and it allows installing different versions in case you need either newer or older versions. The ability to install older versions should not be overlooked because sometimes new versions of packages introduce bugs.
I have reinstalled my operating system (moved from windows XP to Windows 7).
I have reinstalled Python 2.7.
But i had a lot of packages installed in my old environment.
(Django, sciPy, jinja2, matplotlib, numpy, networkx, to name just a view)
I still have my old Python installation lying around on a data partition, so i wondered if i can just copy-paste the old Python library folders onto the new installation?
Or do i need to reinstall every package?
Do the packages keep any information in registry, system variables or similar?
Does it depend on the package?
That's the point where you must be able to layout your project, thus having special tools for that.
Normally, Python packages do not do such wierd things as dealing with registry (unless they are packaged via MSI installer). The problems may start with packages that contain C extensions, so moving to another version of OS or from 32 to 64-bit architecture will require recompiling/rebuilding of those. So, it would be much better to reinstall all packages to new system as written below.
Your demands may vary, but you definitely must choose the way of building your environment. If you don't have and plan to have a large variety of projects you may consider the first approach as follows below, the second approach is more likely for setting up development environment for different projects or for different versions of the same project.
Global environment (your Python installation in your system along with installed packages).
Here you can consider using pip. In this case your project can have requirements file containing all needed packages for your project. Basically, requirements file is a text file containing package names (on PyPI and their versions).
Isolated environment. It can be achieved using special tools or specially organized path.
Here where pip can be gracefully combined with virtualenv. This way is highly recommended by a lot of developers (I must remind that Python 3.3 that will soon be released contains virtualenv as a part of standard library). This approach assumes creating virtual shell with its own instance of Python interpreter and installed packages.
Another popular tool for achieving isolated environment is called buildout. It lays out your project source and dependencies in one path so you achieve the same effect as virtualenv creates. The great advantage of buildout that it's built upon an idea of pluggable recipes (pieces of code implementing different common project deployment tasks) and there are hundreds of stable and reliable recipes over Internet.
Both virtualenv and buildout help you to remove head-ache when installing dependencies and solve the problem of different versions of the same package kept on a single machine.
Choose your destiny...
The short answer to this question is "no", since packages can execute arbitrary code on installation and do whatever the heck they want wherever they want on your system.
Just reinstall all of them.
I have installed two different python versions (3.1 and 2,7) And this is now causing a headache. The default installation is the 3.1 which have the PYTHONHOME and PYTHONPATH set. Problem is that when I try to run scons from the 2.7 installation (via Python27/Scripts/scons.bat) I get various import errors that reference to the Python31/lib/ folder.
Are there any good solutions for this, except changing PYTHONHOME and PYTHONPATH for the whole system. Shouldn't scons be able to work with two versions of python installed?
Not sure if this is a SuperUser or a SO question, but my guess that most people experienced with Python and Scons hangs here, and not in SU.
Try to set PYTHONHOME and PYTHONPATH in the scons.bat scripts to the right values for each Python installation respectively.