Hacker News Reader

Comment by saghm | Hacker News Reader

Most of this seems pretty standard for Linux distros; python2 and python3 installed by default, ability to install venv through `python -m`, other versions of Python and various packages available in the repositories. Is there something I'm missing here?

View on HN

Installing different Python versions is not possible with many distros (you'd have to compile it from source/use something like pyenv):

https://developer.fedoraproject.org/tech/languages/python/mu...

Ah, I missed the "CPython in multiple 3.X and 2.X versions". Thanks for pointing that out to me!

As far as I remember Debian has always been able to support multiple versions of python simultaneously although I think they've dropped packages for <~2.7 now

But:

- iirc they can only go down one version (i.e. 3.4/3.5, no 3.4.1/3.4.2)

- it's always been a real b@llache to install newer versions on Debian releases where it has not been officially packaged (e.g. 3.6 on jessie). With most packages, you can grab the source from Sid and rebuild it on Stable; with Python it's become basically impossible, the pile of dependencies below and above the package is unwieldy. And this despite tons of policies around packaging python apps, which was supposed to make it easier to run multiple versions.

If Fedora really made things easier in this area, it's most welcome. However, when a marketing page starts with "you can now do this standard thing that actually most people have been doing for years already" (-m venv), I'm somewhat skeptical.

OpenSUSE gives you the ability to have both python and python3 installed through the package manager

almost every distro has that. this is about different 3.x versions. SuSE might have that, but I don't know.

Oh that's a good point. I don't think openSUSE has various 3.x versions of python - currently Leap 42.2 ships with 3.4.2. If I need another version of python I use anaconda, but my use cases are relatively simple so the system python versions (2.7/3.4) fit for me just fine.

um, venv is included by default in python 3, no need to install any package.

It's a subtle stab at Debian-based distributions, where pip and venv are only available as optional, non-default packages. (I think Debian really wants people to use apt to install things.)

I think it's probably actually just because they want to support users who wish to have a "minimal" python installation. Python is used internally by the system and many applications, but that doesn't mean that features like venv are necessary for them. It does make sense not to install them unless needed.

That said, I think debian users should lean heavily on the apt versions of any python modules. I will usually install as many modules with apt as possible and then use `python3 -m venv --system-site-packages` to have access to them. That way there are usually very few packages I need to compile/install myself. Seems like a pretty good balance.

i do it the other way around and only use the interpreter, the rest comes from pypi or, preferably, an internal pypi mirror.

yeah it's a much better approach when you want to make sure that your requirements.txt file contains all the requirements

venv is actually a module of the stdlib in Python 3, so you can use python -m venv even on debian. You are confusing with virtualenv, which is a different tool than venv with the same purpose.

pip is another beast: it's not included in the stdlib, but installed when you install Python with the ensurepip script. Debian just don't run the script.

Yes, venv is supposed to be part of the stdlib in Python 3. But that is not the case on Debian. You need to install the python3-venv package to get it. That's what I and that Fedora page are talking about.

I don't think python2 is installed by default.

Reply on news.ycombinator.com