Add bootstrap functionality for environments (python version, plus uv inside environment)

[paxsali]

Hi all,

I'd like to propose a new cmdline target bootstrap that creates a new environment with uv installed in it, and with a specific python version.

So basically, in order to explain this feature request, I have to talk about my workflow.

I'm working a lot with different containers, where the underlying OS (and package manager) may be very different every time.
There may be no guarantee that the OS has a "recent enough" python version available from the default package manager, nor that uv itself is available as a package in the OS'es repository.
In fact, the the only true requirement is that there's a python >= 3.3 installed (for venv - you'll see later why).

In order to explain my "bootstrapping process" I can show what commands I usually do, since that would be more easy:

# 1. start & enter container

### PHASE 1

# 2. create a throw-away environment that's just for bootstrapping uv
python3 -m venv ~/.myenvs/bootstrap-uv

# 3. enter the new environment
source ~/.myenvs/bootstrap-uv/bin/activate

# 4. install uv inside "bootstrapping environment"
pip install uv

# 5. install one or more desired python versions
uv python install cpython-3.12.8-linux-x86_64-gnu

# 6. prepare a second throw-away environment that's based on the target python version you're interested in
mkdir ~/.myenvs/py312-env
uv venv --python 3.12.8 ~/.myenvs/py312-env

# 7. exit the "bootstrapping environment" and delete it. it will never be used again.
deactivate
rm -fr ~/.myenvs/bootstrap-uv

### PHASE 2

# 8. enter the new python version-specific environment (created by uv)
. ~/.myenvs/py312-env/bin/activate

# 9. create the true (final) target environment
python3 -m venv ~/.myenvs/myenv

# 10. exit the throw-away python environment now. it will never be used again.
deactivate
rm -fr ~/.myenvs/py312-env

### PHASE 3

# 11. enter the true target environment, based on the python version that was installed by uv
source ~/.myenvs/myenv/bin/activate

# 12. notice this environment HAS NO uv installed, yet! install uv in the proper python environment.
which uv  # empty output, exit status: 1
pip install uv

# FINISHED

# optional extra steps:
## upgrade pip itself
uv pip install --upgrade pip

## show installed packages
uv pip list

## create projects, work with uv, have fun ...
mkdir ~/projects
uv init --package ~/projects/sample_project

# when done:
deactivate

Now to explain in simple words, what bootstrap whould do is:

• create an environment with a specific version of python
• but also one where the latest uv itself is also installed (and specifically NOT just a copy from the OS, but a "fresh from the internet" one)

The bootstrap option should therefor be able to take as arguments at least --python (like from uv venv) and PATH at minimum.

Oppon activation of the "bootstrapped" environment there must be a guarantee that the active python version comes from uv's own list (as opposed to coming from the OS) and the environment-specific uv version is a fresh, new install (as opposed to the versions from the OS, if any at all) - I can imagine using the command curl -LsSf https://astral.sh/uv/install.sh | sh for this process, if curl is available, else simply use pip install uv internally.

Obviously the details, like what other options to offer on top of that, must be fleshed out.

But the gist of the idea is to have something like a uv venv ..., but with a guarantee that the latest uv version will be contained inside the environment, essentially taking away the requirement that uv must be available from an OS repository.
Another way of thinking about it is this: you only need to somehow install uv once (no matter from where, OS-wide or env-specific), and then you'll use that to create your desired python environment, with the latest uv as a result (no matter any OS repository restrictions).

I admit the feature request may sound rather "niche". Certainly I am totally content with my "manual commands" workaround for the moment, but still I'll leave this issue as an idea for discussion.

Thank you.

[jromal]

I see you speak about containers. But it would be great to have a bootstrap also for calls on the operative system:

• Check if uv is installed, if not, install uv from the download link (e.g. for windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex")
• Check the path is set and visible to the bootstrap and if not set it or use the "./local/bin" folder for calling uv or uvx.
• execute the uv or uvx command that was requested. In case of uvx, already installs the tool if missing.

Then you can pack a call to a program, module or tool with some parameters in a batch/sh file or whatever used on each OS, and there is no need to worry about uv being properly installed. uv could stay or be removed after processing depending on the needs and use cases.