Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exclude pip from the app image #255

Closed
edmorley opened this issue Aug 29, 2024 · 1 comment · Fixed by #264
Closed

Exclude pip from the app image #255

edmorley opened this issue Aug 29, 2024 · 1 comment · Fixed by #264
Assignees
Labels
enhancement New feature or request semver: major

Comments

@edmorley
Copy link
Member

edmorley commented Aug 29, 2024

Once pip is installed into its own layer (see #254), it will be possible to make the layer be a build time only layer (and thus exclude pip from the run image) should we wish.

Doing so would:

  • prevent support tickets where customers have tried to add dependencies to their app in a one-off dyno at run-time using pip install, not realising that each dyno is separate and has an ephemeral filesystem (this happens more than one might expect)
  • prevent the pitfalls from apps trying to pip install packages at app boot (eg via web: pip install foo && ... in their Procfile) - which leads to slow app boot, non-determinism (each time a dyno boots a different version of a package or its transitive dependencies can be installed), and reliability issues (if PyPI is down the app can't start)
  • help with the supply chain surface area (which will become increasingly relevant once we add SBOMs and users start being more app-image dependency conscious)
  • reduce app image size by 13 MB
  • mean fewer layers have to be pushed to the remote registry
  • match the approach used for Poetry apps, where we don't make Poetry available at run-time either.

Users that needed pip at run-time for a temporary task could use python -m ensurepip --default-pip to make it available again (this command doesn't even have to download anything - it uses the pip bundled with Python).

Or if pip is an actual run-time dependency of the app, then the app can add pip to its requirements.txt (which much more clearly conveys the requirements of the app, and also allows the app to pick what pip version it needs at run-time - something that isn't possible with the pip installed by the buildpack).

Open questions:

  1. Are there any use-cases (beyond one-off debugging) that need pip at run-time? (pip doesn't have a pip run type command, so I'm struggling to come up with any use-cases where it might be used as part of normal day to day app operation)
  2. Should we add a shim pip script that does something like echo "pip isn't installed at run-time, if you need it temporarily run 'python -m ensurepip --default-pip' to install it" && exit 1 to improve discoverability?
  3. Should there be an option to make pip be permanently available at run-time after all? (Though I'd prefer not to add extra options where possible)

GUS-W-16697386.

@edmorley edmorley added enhancement New feature or request semver: major labels Aug 29, 2024
edmorley added a commit that referenced this issue Aug 30, 2024
pip is now installed into its own layer (as a user site-packages
install) instead of into system site-packages in the Python layer.

This is possible now that the user site-packages is no longer being
used for app dependencies, after the switch to venvs in #257.

pip being in its own layer has the following advantages:
1. We can more easily exclude pip from the build/run images when using
   other packages managers (such as for the upcoming Poetry support).
2. A change in pip version no longer unnecessarily invalidates the
   Python layer.
3. In the future we could more easily exclude pip from the run image
   entirely, should we wish (see #255).

This has been split out of the Poetry PR for easier review.

Closes #254.
GUS-W-16616956.
edmorley added a commit that referenced this issue Aug 30, 2024
pip is now installed into its own layer (as a user site-packages
install) instead of into system site-packages in the Python layer.

This is possible now that the user site-packages is no longer being
used for app dependencies, after the switch to venvs in #257.

pip being in its own layer has the following advantages:
1. We can more easily exclude pip from the build/run images when using
   other packages managers (such as for the upcoming Poetry support).
2. A change in pip version no longer unnecessarily invalidates the
   Python layer.
3. In the future we could more easily exclude pip from the run image
   entirely, should we wish (see #255).

This has been split out of the Poetry PR for easier review.

Closes #254.
GUS-W-16616956.
edmorley added a commit that referenced this issue Aug 30, 2024
pip is now installed into its own layer (as a user site-packages
install) instead of into system site-packages in the Python layer.

This is possible now that the user site-packages location is no longer
being used for app dependencies, after the switch to venvs in #257.

pip being in its own layer has the following advantages:
1. We can more easily exclude pip from the build/run images when using
   other packages managers (such as for the upcoming Poetry support).
2. A change in pip version no longer unnecessarily invalidates the
   Python layer.
3. In the future we could more easily exclude pip from the run image
   entirely, should we wish (see #255).

This has been split out of the Poetry PR for easier review.

Closes #254.
GUS-W-16616956.
@edmorley edmorley changed the title Exclude pip from the run image Exclude pip from the app image Sep 4, 2024
edmorley added a commit that referenced this issue Sep 4, 2024
After #254, pip is now installed into its own layer rather than into the
system site-packages directory inside the Python layer.

This means its now possible to exclude pip from the final app image, by
making the pip layer be a build-only layer.

Excluding pip from the final app image:
- Prevents several classes of user error/confusion/bad app design
  patterns seen in support tickets (see #255 for more details).
- Reduces app image supply chain surface area.
- Reduces app image size by 13 MB and layer count by 1, meaning less
  to have to push to the remote registry.
- Matches the approach used for Poetry, where we don't make Poetry
  available at run-time either.

Users that need pip at run-time for a temporary debugging task can run
`python -m ensurepip --default-pip` in the container at run-time to make
it available again (this command doesn't even have to download anything
- it uses the pip bundled with Python).

Or if pip is an actual run-time dependency of the app, then the app can
add `pip` to its `requirements.txt` (which much more clearly conveys the
requirements of the app, and also allows the app to pick what pip
version it needs at run-time).

Closes #255.
edmorley added a commit that referenced this issue Sep 4, 2024
After #254, pip is now installed into its own layer rather than into the
system site-packages directory inside the Python layer.

This means its now possible to exclude pip from the final app image, by
making the pip layer be a build-only layer.

Excluding pip from the final app image:
- Prevents several classes of user error/confusion/bad app design
  patterns seen in support tickets (see #255 for more details).
- Reduces app image supply chain surface area.
- Reduces app image size by 13 MB and layer count by 1, meaning less
  to have to push to the remote registry.
- Matches the approach used for Poetry, where we don't make Poetry
  available at run-time either.

Users that need pip at run-time for a temporary debugging task can run
`python -m ensurepip --default-pip` in the container at run-time to make
it available again (this command doesn't even have to download anything
- it uses the pip bundled with Python).

Or if pip is an actual run-time dependency of the app, then the app can
add `pip` to its `requirements.txt` (which much more clearly conveys the
requirements of the app, and also allows the app to pick what pip
version it needs at run-time).

Should we find that pip's absence causes confusion in the future, we
could always add a wrapper/shim `pip` script in the app image which does
something like:

```
echo "pip isn't installed at run-time, if you need it temporarily run 'python -m ensurepip --default-pip' to install it"
exit 1
```

...to improve discoverability.

We'll also document pip (and Poetry) being available at build-time only
in the docs that will be added by #11.

Closes #255.
@edmorley
Copy link
Member Author

edmorley commented Sep 4, 2024

So I'm leaning towards trying to do this sooner rather than later, since it's a change that really needs to be made whilst CNBs on Heroku are still in preview, rather than after they GA (reach General Availability).

Ref the open questions:

  1. I still can't think of any use-cases, and the only way we're going to find them is via feedback, which is what the preview process is for.
  2. I think we can skip this initially - since it's easy enough to add later, and whether it's worth doing or not depends on the feedback we get / whether users are confused after the docs are finished etc.
  3. I don't think we should support this for now since (a) if an app really does have a use-case for needing pip permanently at run-time (vs one off debugging by a human in a single container) then it can (and IMO really should) add pip as a dependency in its requirements.txt file, (b) more buildpack options means more to test, document, maintain - and so something we should not add until we know there is definitely a need for it.

@edmorley edmorley self-assigned this Sep 4, 2024
edmorley added a commit that referenced this issue Sep 9, 2024
After #254, pip is now installed into its own layer rather than into the
system site-packages directory inside the Python layer.

This means its now possible to exclude pip from the final app image, by
making the pip layer be a build-only layer.

Excluding pip from the final app image:
- Prevents several classes of user error/confusion/bad app design
  patterns seen in support tickets (see #255 for more details).
- Reduces app image supply chain surface area.
- Reduces app image size by 13 MB and layer count by 1, meaning less
  to have to push to the remote registry.
- Matches the approach used for Poetry, where we don't make Poetry
  available at run-time either.

Users that need pip at run-time for a temporary debugging task can run
`python -m ensurepip --default-pip` in the container at run-time to make
it available again (this command doesn't even have to download anything
- it uses the pip bundled with Python).

Or if pip is an actual run-time dependency of the app, then the app can
add `pip` to its `requirements.txt` (which much more clearly conveys the
requirements of the app, and also allows the app to pick what pip
version it needs at run-time).

Should we find that pip's absence causes confusion in the future, we
could always add a wrapper/shim `pip` script in the app image which does
something like:

```
echo "pip isn't installed at run-time, if you need it temporarily run 'python -m ensurepip --default-pip' to install it"
exit 1
```

...to improve discoverability.

We'll also document pip (and Poetry) being available at build-time only
in the docs that will be added by #11.

Closes #255.
GUS-W-16697386.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request semver: major
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant