1

So, I wanted to run Python 3.4.x inside a virtualenv virtual environment. I learned that the first step should be to build Python 3.4.x.

I was doing so in /usr/bin/Python3.4.x (a folder I created), where I had extracted Python3.4.x stuff. Then ran ./configure, make, and then did sudo make install. As that command was doing its work, I realized that I might have messed up pretty badly by overwriting core Debian stable Python.

A simple test of running python in terminal shows that I am still using Python 2.7.x, so it seems that I am okay, but I have no clue. Doing something like sudo make uninstall is not an option because I don't think Python makefile comes with uninstall rules for make.

Doing something like sudo apt-get install --reinstall python also doesn't do much, leaving me feeling like I am safe, since reinstall didn't have to overwrite any files?

In any case, I am not sure what I just did, and I am not sure what the consequences are. Could someone help me understand?

I finally understand why the instructions I was following suggest that I configure and make using /opt/some_folder prefix, but its something I omitted...and now...yeah.

bzm3r
  • 363
  • 1
  • 2
  • 15
  • 2
    A sensible approach to this would be to backport Python 3.4 from Debian testing/unstable, which is almost certainly do-able, and probably not very hard. See http://unix.stackexchange.com/q/112157/ – Faheem Mitha Dec 20 '14 at 22:33
  • Thanks @FaheemMitha -- that's a very straightforward tutorial for something I considered too complicated to bother with. – bzm3r Dec 20 '14 at 22:41
  • Glad to hear it. You're the first person to say that. If you have questions, need more detailed directions etc., ask. – Faheem Mitha Dec 20 '14 at 22:43
  • @FaheemMitha now that what's done is done though, could I ask you for recommendations as to what I could do next to confirm that there are no problems, etc.? I think the answer I have right now assumes that Debian Wheezy comes with Python 3.4, which is not the case? – bzm3r Dec 20 '14 at 23:03
  • @FaheemMitha I was digging through the configure file for Python3.4.x and I found that the default prefix /usr/local/ (so stuff is in /usr/local/lib/python3.4 and /usr/local/bin/ etc.)...it seems like I am safe? – bzm3r Dec 20 '14 at 23:10
  • Yes, by default a make install should put things in /usr/local. However, running such a local install as root is generally a bad idea. In any case, you are certainly (in this case, and in general) better off with a backport. A backport is much more likely (though not guaranteed) to integrate seamlessly into your system. – Faheem Mitha Dec 21 '14 at 08:00

2 Answers2

1

The problem of overwriting default python version is still actual.

As said in the README.rst, use sudo make altinstall to avoid overriding the OS default version:

On Unix and Mac systems if you intend to install multiple versions of Python using the same installation prefix (--prefix argument to the configure script) you must take care that your primary python executable is not overwritten by the installation of a different version. All files and directories installed using make altinstall contain the major and minor version and can thus live side-by-side. make install also creates ${prefix}/bin/python3 which refers to ${prefix}/bin/pythonX.Y. If you intend to install multiple versions using the same prefix you must decide which version (if any) is your "primary" version. Install that version using make install. Install all other versions using make altinstall.

For example, if you want to install Python 2.7, 3.5, and 3.6 with 3.6 being the primary version, you would execute make install in your 3.6 build directory

freezed
  • 226
0

First of all: you don't need to build python to run it in a virtualenv, you could have just used the Python3.4.2 provided by the system:

virtualenv -p /usr/bin/python3.4 /path/to/your/venv

You might be in trouble, if you overwrote the system executable and/or its libraries. One of the ways to test this, is running /usr/bin/lsb_release and see if it still works. That is one of the utilities already based on python3 (others are still on python2.7) and it is invoked by apt-get, so when it fails you are in trouble. Try to reinstall python3 if you can, just to make sure you overwrite any traces from your compilation and install.

It would also be good to share, where you got the incorrect information that you need to build python yourself. So people might avoid that information in case it is not corrected.

Anthon
  • 79,293
  • I didn't have a /usr/bin/python3.4 provided by the system, as far as I can see. That's how I got the impression that I had to build it first? – bzm3r Dec 20 '14 at 22:21
  • Also, I get a "No LSB modules are available" when I run your test command. – bzm3r Dec 20 '14 at 22:22
  • @user89 that message is ok. If things are broken you get no module found. I only have Jessy installed to compare, as well as Linux Mint 17 and they both have several of the programs with python3, but maybe that is not so on Wheezy. You could try grep -l python3 /usr/bin/* to see any of the scripts there do use it. – Anthon Dec 20 '14 at 23:14
  • @user89 the default python in Debian is still 2.7, but there is a python3.4 available, in the python3 package. Install that, it'll work then. – Wouter Verhelst Jul 18 '15 at 10:59
  • @WouterVerhelst not really, he specified that he's using wheezy and the version available on it is 3.3, not 3.4 – To마SE Jan 19 '16 at 11:46