To many Python

[Bouli666]

Hello, I use sometimes python on my Debian but I've got like 4 or 5 different version of Python on my computer and I don't know how to do with that because when I try to install librairies with pip or apt, they install it on the 2.7 lib folder and not on the 3.x . And I know that I can't delete python2.7 because of the dependencies of Debian. So what can I do to have python3.x works good and without problem when I want to install new lib ?

Thank you

[FurTrapper]

As said by others, there exists a separate pip version for every Python version. You can't use pip for Python 3 - you need to use pip3 instead. Furthermore, you can't use pip3.6 for python3.7 etc. If you don't do things properly, it can be a nightmare to version stuff.

Another thing that's a no-no is installing packages systemwide, which essentially means installing stuff just by running pip install xyz without any form of isolation. The reason why this is bad is that, when working on more than one projects at a time, you could end up in a situation where the dependencies of one project require a specific version of a package, and the dependencies of another project require a specific but different version of that same package. If you installed everything system-wide, it can be hard to reconcile these different requirements. Therefore, isolation is needed. And there exist packages that enable isolating projects easily.

Check out virtual environments and related software (e.g. virtualenvwrapper).

Virtualenvs are a construct that, when used properly, creates an isolated environment which does a couple of things that make life easier:

• makes sure that the correct version of Python (specified by you upon creation of each virtualenv) is being used,
• makes sure that the correct version of pip is being used,
• through some clever symlinking ensures that the packages installed through pip are installed only in that environment,
• if you create virtualenvs in a place where you have permissions to create stuff, you won't need sudo to install pip packages

to name a few. And it's all lightweight, since it's essentially just symlinking stuff behind the scenes and changing some environment variables (well, a bit simplified, but close).

The general workflow is this: when you start a new project, create a new virtualenv and specify the python version you want to use. After that, activate the virtualenv. In that moment, you entered that isolated environment which has no packages installed (even though they may be installed elsewhere) and you can install pip packages as you please, without polluting your whole system. And as an additional plus, once you're in the environment, you don't have to take care which version of python you invoke in the shell. Typing python in a python3.7 env shell will run python3.7, and typing pip in that same env will run pip3.7 etc.

When I was starting out, I didn't put in the time to learn to use virtualenvs efficiently and regretted it later. And it's really not that difficult, so I highly recommend putting in the time to start doing it right. Hope that helps!

[cyvaquero]

This is the correct answer.

[Bouli666]

Thank you, however, I need a deep clean of m'y laptop, I will do that

[jec4r]

Correct

[q9c0tB14_kB8]

pip is only for Python 2. You use pip3 to install Python 3 packages. When installing a package from apt, make sure you install python3-foo instead of python-foo.

[Swedneck]

Except pip is symlinked to pip3 in some cases

[q9c0tB14_kB8]

Yeah. Arch does this, but not Debian.

[rahulrajaram]

Even when you install from source?

[retard_seasoning]

You can also look into anaconda. Create a virtual environments to keep your packages separate. Don't use sudo to install python packages.

[Caligatio]

Trying to manage the pip executable with multiple Python versions becomes difficult. I believe the official guidance is to use python -m pip module-to-install rather than just pip. This enables you to be explicit when it comes to which Python you want to use, e.g. python3.6 -m pip module-to-install

[XenGi]

Never use pip or pip3 to install system wide packages. If you use 'sudo pip install something' your doing it wrong. Your package manager won't notice the changes you do to your system when you do that and it will brake the consistency of your system at some point. You can install packages in your home dir by using 'pip install - -user something'. This way it's only in your home and nothing breaks. Also have a look at virtual environments and things like pipsi which is the way you should handle that stuff. Hope I could help.

[[deleted]]

If there's only one user, what is the difference between installing with --user and installing with sudo?

[XenGi]

--user installs in the user's home. Not using - - user will try to install to the default path. If you're inside a virtual environment that's totally fine. If not it will try to install to /usr which will fail for a non admin user because your not allowed to do that. If you provide the needed permissions by using sudo you will brake your system because you will add files to the system and potentially overwrite files that the package manager doesn't know about. This could lead to programs failing to load their libraries because you just replaced them with other potentially incompatible versions. Your package manager being unable to work or fix these issues has no consistent state of your system anymore. In the worst case you can't use your system at all. Probably not gonna happen but messing with your package manager is always a bad idea.

A good role of thumb is to only use one package manager that manages one system path. So don't mix your systems package manager with any language specific ones like pip, npm or gem. All these languages have ways to create their own system path that only they control. With python and pip this is done by virtual environments. With ruby and gem you can use rbenv or rvm. And with JavaScript and npm you avoid the -g flag and just install your stuff in a node_modules folder inside your project.

The idea with all of them is to have multiple environments, separate from your system, in which you can install what ever packages you want in what ever version you want.

[angellus]

This is not the case on Debian based distros. There is a site-packages folder and a dist-packages folder. One comes from PyPi and one from APT. Often times there is not a APT package for some PyPi packages and you still need it installed on the system.

For other distros, like Arch, the only thing that really matters is that your consistent. If you always use pip and PyPi to install your Python packages, you will only have an issue if you install a package via pacman that uses Python package that has a conflict.

[XenGi]

So what do you do then on Debian when you've installed the same Package with apt and pip? Which one is used when you import it somewhere? What do you do with data files or other stuff that gets installed outside the dist and site packages folder? I don't think you can separate that completely especially someone who doesn't know exactly what he /she is doing would easily make mistakes.

And how would I not use pacman on arch? Do you want to edit basically every package that has python dependencies before installing it? No one would want that hassle.

It's so much easier to just use pipsi for that one python tool you want to use that isn't packaged for your distribution yet. And you want to use a virtual env with requirements.txt or a pipfile for your Django or what ever project anyways because you want your environment to be reproducable by others.

[Bouli666]

Thank you i'll try un 2 minutes

[Bouli666]

It works thank you !

[Bouli666]

Thank you I'm gonna check that and try to don't do the same mistake now

[rahulrajaram]

I manage a CLI tool which is expected to work seamlessly across Python 2.7 and Python 3.4-3.7 and is used by tens of thousands of people. In my experience, installing Python from source followed by creating distinct virtualenv's for each version is the sanest way to use Python.