python-debian.sh: use pyenv to install Python

[felipecrs]

The installation of Python when built from source takes quite a while. In my working laptop, it often takes around 30 minutes.

It would be very cool if we could use pyenv (as suggested by @Chuxel) to install Python.

pyenv is for Python what nvm is for Node and sdk is for Java. This is a huge gain for the developers since they could easily switch between Python versions in order to make a quick test without having to rebuild the entire container.

This issue started as Use ppa:deadsnakes to install Python but it's now about pyenv.

[felipecrs]

There must be also a way to install .debs from PPAs on Debian systems.

[Chuxel]

There must be also a way to install .debs from PPAs on Debian systems.

@felipecrs I am not aware of any official builds like this and while it might work in theory, it's clearly not an intended use by the maintainers. Deadsnakes also doesn't cover whatever ships in the specific version of Ubuntu. https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa

Certainly, happy to be pointed to debs that exist. Python seems to be one of the few platforms that relies on things being shipped in the distro.

[felipecrs]

I saw somewhere that you can add a PPA repository in Debian by pointing to the Ubuntu codename which was based in the same Debian version.

Example:

If installing on Buster, add the PPA using bionic as the platform codename.

But it's not an official solution despite it might work. I'm just discussing though, not asking for such a thing.

Nonetheless, I use Ubuntu as the base image for all my devcontainers (and I wonder why someone would prefer Debian instead). There must be also more people doing such thing, despite the use of Debian is enforced (I mean: default) for the Codespaces.

So I believe it's harmless to include a check in python-debian.sh to perform the installation using the PPA instead from source if the OS is Ubuntu.

If you agree, I can make a PR.

[Chuxel]

In this repository, we want to stay on supported paths since we will need to maintain things in the long term, so we wouldn't want to do something that was not officially documented even if it might work now.

The reason for Debian is this is what official images use (sometimes in addition to Alpine or with OpenJDK oracle Linux):

https://hub.docker.com/_/node https://hub.docker.com/_/python https://hub.docker.com/_/rust https://hub.docker.com/_/ruby https://hub.docker.com/_/golang https://hub.docker.com/_/swift

These scripts should allow a developer to grab any one of these images and add what they'd like to them. You may absolutely use Ubuntu as your base if that's your preference, but hopefully that helps explain the reasoning for the script focus.

While deadsnakes is great, the "Team for maintaining unofficial Python packages for different releases of Ubuntu" makes me worry about flat out recommending it. Even solutions like pyenv build from source (which we could use here potentially).

This is a bit different than git where Git itself is making the recommendation - here the only official source for Linux is a tar ball. It's a tough one.

[felipecrs]

I understand the reasons and would be happy to see pyenv instead. Thanks for pointing it, it seems to be what nvm is for Node and sdkman is for Java. A much better approach and totally aimed for developers!

About the Debian as base image, I got your point now. However, all these docker images, despite official, were not made for development or for developers. They were made for production environments, and this is where Debian would be a better fit than Ubuntu.

I also believe that there is no much advantages of using those official images, because: you as a Node.js developer, would not you prefer to have a container with NVM instead of a fixes Node version? This applies to Java, and to Python now as well.

In my opinion, if all the "language" images were moved from their official docker images to a common base image (such as the Ubuntu provided by this repository), it would make much more sense maintaining those scripts, since they would be used always (python-debian.sh is not used in Python's devcontainer for example).

Again, this is just my opinion. I hope it could contribute somehow.

[Chuxel]

Oh! One more point - if python is already installed, the script it will skip installing python and just install the tools.

. However, all these docker images, despite official, were not made for development or for developers.

The reason they contain git among other things is so that you can use them for both building and running your application during development. Node includes yarn for similar reasons. Most of these originate from the buildpack-deps base image which itself is not intended as a deployment image. There's also a huge value if you are doing container deployment in using the same base for development that you do for deployment.

That said, nvm is added to many of these images since Node is often combined with something harder to install - like Python or Go. The idea is to start from a known, solid base, then add rather than reinvent from the ground up. No image can fit all needs, which is why we're also trying to get things in a reusable form for custom solutions.

Different scenarios for different people, but one set of scripts to cover them both - but the balancing act is tough, so not saying it's there yet. :smile:

Of curiosity, if you assume for a moment that we would not want to use PPAs that are not official - what advantage does Ubuntu provide over Debian for you?

[felipecrs]

I'll open a different issue to track this, other people might be also interested. @Chuxel can you please reply there instead?

[felipecrs]

@Chuxel I'll rename this Issue as "use pyenv in python-debian.sh".

Oh! One more point - if python is already installed, the script it will skip installing python and just install the tools.

It makes sense if coming from the official python image. I hope we still install pyenv in this case so.

[davetapley]

Just throwing it out there: If the new Python Install Script could check for a .python-version, then it might provide this functionality?

... alternatively that script could be updated to use pyenv under the hood.

... or this issue could be solved with an entirely new pyenv install script feature? 🤔

[edxu96]

I'm wondering if anyone has successfully installed pyenv. I tried to include the pyenv-installer in the Dockerfile based on Ubuntu, but the installed pyenv cannot be found, after vscode run the container.

[hoechenberger]

@edxu96 We added the following postCreateCommand to devcontainer.json:

    "postCreateCommand": {
        // Install pyenv
        "install-pyenv": "curl https://pyenv.run | bash",
        "add-pyenv-to-path": "echo 'export PATH=\"$PYENV_ROOT/bin:$PATH\"' >> ~/.zshrc && echo 'eval \"$(pyenv init -)\"' >> ~/.zshrc",
        ...
    }

Ideally, we'd turn this into a Dev Container Feature, but didn't have the time yet.