How To Install CPython from Github `main` Branch in an Isolated Way?

Core Development
1

Somebody shared a bug using the latest version of Python from the main branch. I want to reproduce the bug, but I do not want an installation from whatever commit main happens to be on to leak into other projects on my computer, hence no pip install git+https://github.com/cpython/cpython.git@main.

How do core developers run the main version of Python in an ephemeral way to reproduce bugs like this? My end goal is running the same Python interpreter as the person that shared the bug. I’m fine compiling from source according to these docs, but I suspect there’s a quicker way. I’d be fine using UV or Pyenv or any similar software to contain the Python version to a project in a single directory.

3 Likes
2

The easiest way is usually to build, but not install. After ./configure and make, you will have an executable Python interpreter right there in the build directory. It’s not interfering with anything, but you can run that directly to test out the code.

If testing the bug requires that you install packages using pip, then I’d recommend using the freshly built Python to create a venv and working from there.

7 Likes
3

The fastest way to test small stuff is probably to use a github codespace which you can quickly create from the github CPython page.

4

Use ./configure --prefix="$(pwd)/build". If you’re on openSUSE, you can also use ./configure --prefix="$(pwd)/build" --with-platlibdir=lib64. If your openssl installation is in a weird place, you should also add it (see Using custom OpenSSL version 3.x when compiling Python 3.x - fails · Issue #121992 · python/cpython · GitHub for some workarounds).

5

I like using pyenv to manage from-source builds of Python. Some people don’t like how it uses shim scripts but I like how I don’t need to manually think about paths.

You can do e.g. “pyenv install 3.15-dev” to get a build of the CPython main branch.

4 Likes
6

The advantage of doing it this way over the other methods is that you can then check out different commits i.e. I would envisage the next step being git bisect. You need a ./configure && make at the start but then when git checks out a new commit you can usually get away with just a make but sometimes ./configure is needed again depending on how far git has moved you.

If you don’t necessarily need the absolute tip of main you might be able to get away with an alpha or beta release that you could install with uv although current main is 3.15 which has no prereleases.

1 Like
7

Thanks all. I ended up running

./configure --prefix="$(pwd)/build"
make
./python

to reproduce the error. I’ll do a git pull and repeat for the next time I want to run the interpreter on the latest commit.

8

For future reference you may find the Python Developer’s Guide useful.

A

6 Likes
9

Also you can use make altinstall

10

You should always do a clean build. Our build system is not reliable if you switch between commits. When bisecting, I always start my repro script like this:

set -e
git clean -fdx
./configure  # using whatever options I need for the repro
make
# <= here comes the repro commands, usually some variant of executing the locally built python.exe
2 Likes