I downloaded and built a new installation of Python on my Ubuntu 12.04 system without realizing that Ubuntu already comes with it installed.
Whatever I did messed things up as one of the modules I need is no longer working. Is there a way to revert back to the original install?
Thx!
Just never build anything like this using ./configure && make && make install on systems with package manager. This may (and will) cause unforeseen consequences.
In order to uninstall what you have installed without package manager cd to folder with makefile and perform make uninstall.
If you want to install other version of python alongside with your existing version, find appropriate package and use update-alternatives to choose default one.
Related
I installed some package via pip install something. I want to edit the source code for the package something. Where is it (on ubuntu 12.04) and how do I make it reload each time I edit the source code and run it?
Currently I am editing the source code, and then running python setup.py again and again, which turns out to be quite a hassle.
You should never edit an installed package. Instead, install a forked version of package.
If you need to edit the code frequently, DO NOT install the package via pip install something and edit the code in '.../site_packages/...'
Instead, put the source code under a development directory, and install it with
$ python setup.py develop
or
$ pip install -e path/to/SomePackage
Or use a vcs at the first place
$ pip install -e git+https://github.com/lakshmivyas/hyde.git#egg=hyde
Put your changes in a version control system, and tell pip to install it explicitly.
Reference:
Edit mode
You can edit the files installed in /usr/local/lib/python2.7/dist-packages/. Do note that you will have to use sudo or become root.
The better option would be to use virtual environment for your development. Then you can edit the files installed with your permissions inside your virtual environment and only affect the current project.
In this case the files are in ./venv/lib/pythonX.Y/site-packages
The path could be dist-packages or site-packages, you can read more in the answer to this question
Note that, as the rest of the people have mentioned, this should only be used sparingly, for small tests or debug, and being sure to revert your changes to prevent issues when upgrading the package.
To properly apply a change to the package (a fix or a new feature) go for the options described in other answers to contribute to the repo or fork it.
I too needed to change some things inside a package. Taking inspiration from the previous answers, You can do the following.
Fork the package/repo to your GitHub
clone your forked version and create a new branch of your choice
make changes and push code to the new branch on your repository
you can easily use pip install -e git+repositoryurl#branchname
There are certain things to consider if its a private repository
If you are doing the custom module that you want hot loading, you can put your running code also inside the module. Then you can use python -m package.your_running_code. In this way, you can change the module in the package and reflect the result of your running code immediately.
I have just spent 2 days trying to build Tensorflow from source, and finally succeeded when I realized that sudo pip (even with the -H flag) was not finding my anaconda pip, but instead finding a pip installed with apt. Running, then, sudo -H ~/anaconda3/bin/pip ... fixed my problem.
In order to avoid this kind of issue ever again (I had several issues in this process with the "wrong" python being used), is it possible for me to completely remove python from my system, keeping only Anaconda? Is it advisable?
No, you can't. Python is an essential part of ubuntu (and of just any linux distrib nowadays), so removing it will just break your system. Well, if you want a broken system then it's of course up to you ;)
The right solution is to use virtualenvs for your own workspaces instead, so you can have different isolated installs with different python and 3rd part packages versions. This also avoids breaking anything when two projects depends on different versions of a same package. For a local use you probably want to install virtualenvwrapper too (it's an addon over virtualenv that makes working with virtualenvs easier - switching between virtualenvs, running hooks on env switch etc).
Oh and yes: those virtualenvs are per-user so no more sudo and you don't risk messing up your system install (thx Attie for mentioning this).
And to be even more exhaustive: darthbith mentions in a comment that anaconda has it's own virtualization/package management system conda that might make virtualenv redundant and is anyway a best fit if you're using anaconda.
This is not just a Ubuntu issue but also a linux world wide issue. The system python is at the core of apt-get and yum package managers. Also the modern grub is based on python so removing it can make your machine unbootable.
In short, this will affect RHEL related distributions (CentOS/Fedora) and Debian related distributions (Debian/Ubuntu).
I suppose this would apply to anyone using tools like: virtualenv, virtualenvwrapper, pythonbrew, pyenv, etc.
Let me give the use-case. I am using pythonbrew. I want to create a venv, but I get an Import Error saying that there is no "zlib".
So what I do is, I run this command (linux deb/ubuntu terminal):
sudo apt-get install zlib1g-dev
Now the only way I am aware of making sure that the python version I wanted to use with zlib will now work is to uninstall it and then reinstall it again (for anybody that wishes to know, it now works with zlib being recognized).
This takes a lot of time (installing) and makes me wonder what might happen if I have like 5 venvs with multiple setups, only to realize that I need some new module and have to delete my python version again (to reinstall it) and which may also break the 5 venvs (it may, but I'm not sure).
My question is, how could I make sure that the python version will acknowledge something like the zlib installation above without doing a complete re-install of python?
Is there something I could modify in any of the files or perhaps run some update command?
Can someone please explain to me what is going on with python in ubuntu 9.04?
I'm trying to spin up virtualenv, and the --no-site-packages flag seems to do nothing with ubuntu. I installed virtualenv 1.3.3 with easy_install (which I've upgraded to setuptools 0.6c9) and everything seems to be installed to /usr/local/lib/python2.6/dist-packages
I assume that when installing a package using apt-get, it's placed in /usr/lib/python2.6/dist-packages/ ?
The issue is, there is a /usr/local/lib/python2.6/site-packages as well that just sits there being empty. It would seem (by looking at the path in a virtualenv) that this is the folder virtualenv uses as backup. Thus even thought I omit --no-site-packages, I cant access my local systems packages from any of my virtualenv's.
So my questions are:
How do I get virtualenv to point to one of the dist-packages?
Which dist-packages should I point it to? /usr/lib/python2.6/dist-packages or /usr/local/lib/python2.6/dist-packages/
What is the point of /usr/lib/python2.6/site-packages? There's nothing in there!
Is it first come first serve on the path? If I have a newer version of package XYZ installed in /usr/local/lib/python2.6/dist-packages/ and and older one (from ubuntu repos/apt-get) in /usr/lib/python2.6/dist-packages, which one gets imported when I import xyz? I'm assuming this is based on the path list, yes?
Why the hell is this so confusing? Is there something I'm missing here?
Where is it defined that easy_install should install to /usr/local/lib/python2.6/dist-packages?
Will this affect pip as well?
Thanks to anyone who can clear this up!
I believe Mike Orr's answer from the virtual-env mailing list seems to be the best. Note the OP published this question in both places.
Original content of mail:
Years ago Debian created /usr/local/lib/pythonVERSION/site-packages,
and compiled the Python binary to include it in the default search
path. Ubuntu followed Debian's lead as it normally does. The Python
developers did not like this because you'd get interference with a
locally-installed /usr/local/bin/python using the same site-packages
directory. Ubuntu finally decided to abandon site-packages and use
dist-packages instead, a name which they invented so it wouldn't
interfere with anything. The loing story is out there somewhere if
you google it, somewhere in the Python bug tracker or distutils SIG or
such.
The system works, at least if you use the Ubuntu virtualenv package.
Some people have had problems using a locally-installed virtualenv on
Ubuntu because the magic sys.path entries weren't being added or
something. I'm not sure about --no-site-packages because I never use
that option: I run PIL and mysqldb from the Ubuntu packages because it
can be hard to compile their C dependencies sometimes. (Need the
right header files, Python is ignoring the header files, etc.)
So Ubuntu Python packages go into
/usr/lib/pythonVERSION/dist-packages. Or that python-support
directory for some reason. Locally-installed Python packages go into
/usr/local/lib/pythonVERSION/dist-packages by default. Whenever I
install an Ubuntu 9.04 system I run:
$ sudo apt-get install python-setuptools (6.0c9)
$ sudo apt-get install python-virtualenv (1.3.3)
$ sudo easy_install pip
$ sudo pip install virtualenvwrapper
The virtualenvs work fine this way, although I haven't tried --no-site-packages.
I'm trying to spin up virtualenv, and the --no-site-packages flag
seems to do nothing with ubuntu. I installed virtualenv 1.3.3 with
easy_install (which I've upgraded to setuptools 0.6c9)
These versions are both in Ubuntu 9.04, so you're making it harder on
yourself by installing them locally.
and everything
seems to be installed to /usr/local/lib/python2.6/dist-packages
Yes
I assume that when installing a package using apt-get, it's placed in /
usr/lib/python2.6/dist-packages/ ?
Yes
Is it first come first serve on the path? If I have a newer
version of package XYZ installed in /usr/local/lib/python2.6/dist-
packages/ and and older one (from ubuntu repos/apt-get) in /usr/lib/
python2.6/dist-packages, which one gets imported when I import xyz?
I'm assuming this is based on the path list, yes?
sys.path is scanned in order. The only funny thing is that .pth eggs
get put earlier or later in the path than some people expect. But if
you're using pip for everything it can do (i.e. except to install pip
itself, precompiled eggs, and a snapshot of a local directory that's a
copy rather than an egg link), you won't have many .pth eggs anyway.
Why the hell is this so confusing? Is there something I'm
missing here?
It's not well documented. I figured it out by scanning the web.
Will this affect pip as well?
Yes, pip will automatically install to
/usr/local/lib/pythonVERSION/site-packages. Use "pip install -E
$VIRTUAL_ENV packagename" to install into a virtualenv.
I'd be tempted to hack it by making site-packages a link to dist-packages, but I guess this might affect other cases where you want to install some extension other than from the ubuntu dist. I can't think of another answer to 1 except tweaking virtualenv's sources (with both ubuntu and virtualenv being so popular I wouldn't be surprised to find tweaked versions already exist).
Re 2, if you're using /usr/local/bin/python you should use the /usr/local version of the lib (including site-packages) and conversely if you're using /usr/bin/python.
Re 3, there will be something there if you ever install an extension for /usr/bin/python from sources (not via easy_install or from ubuntu's distro).
Re 4, yes, earlier entries on the path take precedence.
Re 5, easy_install is easy only in its name -- it does so much dark magic that it's been carefully kept out of the standard python library despite its convenience because the consensus among us python committers is that deep dark magic for convenience is "easy" only on the surface.
Re 6, I think that's an ubuntu modification to easy_install -- if that's right then it's defined wherever Canonical or other ubuntu maintainers make their collective decisions.
Re 7, sorry, no idea -- I have no reasonably recent ubuntu at hand to check.
You really should not touch Ubuntu's Python installation unless you are building system admin tools, or building something that could be considered to be a new system service.
If you are using Ubuntu to develop or deploy Python applications, always build your own Python from source, tar it up, and use that for deployment. That way you will have all the directories in the right place and virtualenv will work normally. If you will deploy several Python apps on the server, then make your Python live in some place like /home/python or /opt/python or somewhere outside of your home directory. Make sure that you have write permissions for the developers group (users?) so that people can easily add packages.
This also allows you to have two tiers of packages. The ones that are your in-house standard tools can be installed in your Python distro and be part of the tarball that you deploy, and only the app-specific packages would be in a virtualenv.
Do not upgrade or modify the Ubuntu system installed Python.
Well I have a Ubuntu 9.04 and quickly tried setting up a couple sandboxes with site-packages and one without. And things are working fine.
The only difference in the approach I took is I used Ubuntu's python-virtualenv package (1.3.3). And presume that it is tweaked by Ubuntu team to suit Ubuntu setups.
To sum up disable easy_installed virtualenv for a while, use packaged python-virtualenv and see if that meets your expectations.
In fact we use similar setup for production without any problem. Rest is already answered by Alex.
Another way to fix it:
https://stackoverflow.com/a/17265840/202168
Have to remember to do that in each virtualenv where you need it, but doesn't rely on hacks or a special version of virtualenv
I'd like to how to upgrade the default python installation(2.5.2) supplied with ubuntu 8.04 to python 2.6rc2. I'd like to make 2.6 the default python version on the system and migrate all the other useful installed python libraries installed on 2.5.2 to python 2.6rc2. Please let me know how I can achieve this.
Thanks
Dirk
With the warning that I think it's a tremendously bad idea to replace the default Python with an unreleased beta version:
First, install 2.6rc2. You can download the source from the Python website. Standard ./configure && make && sudo make install installation style.
Next, remove the /usr/bin/python symlink. Do not remove /usr/bin/python2.5. Add a symlink to 2.6 with ln -s /usr/local/bin/python2.6 /usr/bin/python.
Once again, I think this is a terrible idea. There is almost certainly a better way to do whatever you're trying to accomplish.
Migrating installed libraries is a much longer process. Look in the /usr/lib/python2.5/site-packages/ and /usr/local/lib/python2.5/site-packages/ directories. Any libraries installed to them will need to be re-installed with 2.6. Since you're not using a packaged Python version, you cannot use Ubuntu's packages -- you'll have to manually upgrade all the libraries yourself. Most of them can probably be installed with sudo easy_install <name>, but some like PyGTK+ are not so easy. You'll have to follow custom installation procedures for each such library.
I have the same issue, and apparently pre-built binaries can be found here:
# Python 2.6
deb http://ppa.launchpad.net/doko/ubuntu intrepid main
deb-src http://ppa.launchpad.net/doko/ubuntu intrepid main
Is there any need to?
Ubuntu in general doesn't package RC releases. 2.6 will not be available in Ubuntu until Jaunty Jackalope.
However,, if you insist that you need to install it, then, you'll have to do so without a package manager.
Download the package, and unzip it to a directory
run the following commands (waiting for each to finish as you do so)
./configure
make
sudo make install
There, you have it installed.
It's better to wait for it to be packaged first, espescially as Python is used in a lot of ubuntu internals, so may break your system horribly
It would not be wise to change the default version of Python, i.e. what you get when you type "python" into a shell. However, you can have multiple versions of python installed. The trick is to make sure that the program named "python" on the path is the system supplied version. If you want to run your install of Python 2.6 you'd then type python2.6 into a shell to start it.
Download the package and unzip it, then run:
./configure
make
sudo make install
ls -l /usr/local/bin
You should see a python and a python2.6 file, both created on the day you ran make install; delete the python file. Then when python is launched the standard system Python version from /usr/bin will be run, and when python2.6 is run you get your shiny new python 2.6rc2. Python displays the version when it starts an interactive interpreter.