uv is not available in postdeploy

[amureki]

Greetings, fellows!

Many thanks for adding uv support!

We are actively working on switching our Heroku projects to it; however, there are a couple of quirks that we stumbled upon.
The main blocker is that we don't understand how to use it in postdeploy file.

I tried simply putting it like this:

#!/usr/bin/env bash

uv tree

And postdeploy phase fails with the following:

bin/postdeploy: line 3: uv: command not found

Before switching to uv we were managing this with pip:

python3 -m pip ...

But that is also not available anymore, saying pip not found.
I'd be happy to figure out the way, as we need to run a couple of shell scripts for our review apps outside a normal build phase.

Cheers,
Rust

[edmorley]

Hi! uv is intentionally not available at runtime (ideally pip wouldn't be either; though I can't remove it now in the classic buildpack for backwards compatibility reasons, but have removed it already in the Python CNB), since in general one shouldn't be mutating the environment at runtime. (There's a brief mention of this towards the end of #1791's very long PR description 😅)

Could you explain a bit more about your use-case, to see if there is a better way to achieve the same outcome? :-)

[amureki]

@edmorley thanks for a swift reply!
Happy to elaborate. :)

I highly agree that it goes a bit against the good practices.
Here is the postdeploy flow we are having:

1. We do install Heroku CLI and AWS CLI (right now it is done via NPM and pip)
2. With the help of Heroku CLI, we enable maintenance mode
3. AWS CLI is used to do a couple of operations to prepare a dev database backup from s3
4. Then, with Heroku CLI we restore this backup, unset a couple of env config variables and disable the maintenance mode

The other option for these CLI tools would be - to install them via curl, but I believe it is also not available there (and might feel less secure than using package managers).

I'd love to hear your suggestions on such flow!

Best,
Rust

[edmorley]

Ah that makes sense - you're not wanting to permanently mutate the review app environment/packages, but need tools only for the initial DB setup.

The other option for these CLI tools would be - to install them via curl, but I believe it is also not available there (and might feel less secure than using package managers).

curl and wget are both available at runtime too:
https://devcenter.heroku.com/articles/stack-packages

Re installing the AWS CLI via pip, as far as I know the AWS CLI available on PyPI is the legacy v1 CLI:
https://pypi.org/project/awscli/#description

The v2 AWS CLI has a direct downloader - for which there are some curl (and GPG verification) examples in:
https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Another option - there are also buildpacks for the AWS CLI and Heroku CLI:
https://github.com/heroku/heroku-buildpack-cli
https://github.com/heroku/heroku-buildpack-awscli

...which if configured via app.json wouldn't apply to your standard apps, only review apps / Heroku CI (and could be further narrowed down via https://devcenter.heroku.com/articles/app-json-schema#environments), so would avoid bloating your prod slug.

Lastly, I believe python -m ensurepip should also work at runtime - and thus let you continue to use pip to install awscli during the postdeploy script.

[edmorley]

So to summarise - I would try to decide whether you want to continue to install those review-app-setup-related deps in the one-off dyno of postdeploy, and if so, then either use curl or python -m ensurepip && pip ... to do so. Or else, move the deps to be something installed during the build (but only for review apps).

[amureki]

@edmorley awesome, this gives some food for thought!

Meanwhile, I tried switching to curl and was stuck with this:

-----> Installing Heroku CLI

...

This script requires superuser access.

You will be prompted for your password by sudo.

sh: 10: sudo: not found

But I will consider using these buildpacks for my review apps, that could do the trick (even thought it feels as an overkill a bit).

I think, we could close this issue for now as you clarified everything. Many thanks! 👍

Best,
Rust

[edmorley]

@amureki No problem!

As the smallest change, you could do something like this (inside postdeploy) for now:

$ h run bash
Running bash on ⬢ serene-earth-56190... up, run.7781
~ $ pip --version
bash: pip: command not found
~ $ python -m ensurepip --default-pip
...
~ $ pip --version
pip 25.1.1 from /app/.heroku/python/lib/python3.13/site-packages/pip (python 3.13)
~ $ pip install awscli
...
~ $ aws --version
aws-cli/1.40.34 Python/3.13.5 Linux/5.15.0-1077-aws botocore/1.38.35

This uses the Python stdlib's ensurepip module to install its bundled pip:
https://docs.python.org/3.13/library/ensurepip.html

(Note: Without the --default-pip argument to ensurepip, it only installs the pip3 command, not pip too)

Meanwhile, I tried switching to curl and was stuck with this:

Both the build and runtime environments are run in the context of a non-root user without access to sudo, and the AWS CLI defaults to installing to global locations. If you wanted to use this approach, you would need to pass in the --install-dir and --bin-dir options pointing at somewhere writeable (such as /app or /tmp), similar to what the buildpack does:
https://github.com/heroku/heroku-buildpack-awscli/blob/665706f040cf1e9ea003df1e31069c44fafabb64/bin/compile#L40

[edmorley]

Oh and one last thing - if you wanted to skip the need to install the Heroku CLI using NPM (depending on how critical review app deploy times are to your workflow), enabling/disabling maintenance mode is one PATCH call to /apps/<app_name> with body eg {"maintenance": true} - via the public platform API:
https://devcenter.heroku.com/articles/platform-api-reference#app-update

(with the token/headers set according to https://devcenter.heroku.com/articles/platform-api-quickstart#calling-the-api)

That PATCH request is all the Heroku CLI's maintenance command does, e.g.:
https://github.com/heroku/cli/blob/552ceae24dcf2ee7a3bac9c1ba58f9d3fea4b988/packages/cli/src/commands/maintenance/on.ts#L18

[amureki]

Oh great, cool idea about small API request to switch the mode, however I am running a couple more heroku commands, including a Django management command (heroku run python manage.py blah-blah) - so this would be tricky.

And TIL about ensurepip, wow 👏

However, I am testing now the buildpacks setup, thanks for the hint that buildpacks can be set only for review app environment, that was not obvious from the docs.

[edmorley]

including a Django management command (heroku run python manage.py blah-blah)

I might be misunderstanding, but running this within the postdeploy step will be creating an identical one-off dyno to run the manage command, when the manage command could be run directly inside the postdeploy dyno instead to save some time.

[amureki]

including a Django management command (heroku run python manage.py blah-blah)

I might be misunderstanding, but running this within the postdeploy step will be creating an identical one-off dyno to run the manage command, when the manage command could be run directly inside the postdeploy dyno instead to save some time.

Aha, great catch! This can be optimized, true that.
Many thanks for great insigts, Ed! 🏅

Cheers,
Rust