Problem
Sometimes tools need some system dependencies like:
- imagemagik
- pstools
And currently buildpacks don't allow to install any system packages.
Constraints and risks
- Users will not be able to use the buildservice and request adding extra packages to the existing toolforge docker images
- Users might not be able to migrate out of the grid without a big refactor
Decision record
Options
Option 1
Allowing to install apt packages using upstream apt buildpack (https://github.com/heroku/heroku-buildpack-apt).
This can be done by injecting that buildpack to the generated groups.toml (after detection).
We should put this feature behind an access list, enabled for certain projects after request.
Pros:
- Unblocks any users that need extra dependencies
- Still pushes users to use the recommended way to pull dependencies with buildpacks (pip/composer/bundler/...)
Cons:
- For users that need it, they will have to do an extra request to enable it
- A bit more complicated code-wise (we have to implement some sort of allowlist, we might use it for other things too ex. multistack/custom buildpacks)
Option 2
Allowing to install apt packages using upstream apt buildpack (https://github.com/heroku/heroku-buildpack-apt).
This can be done by injecting that buildpack to the generated groups.toml (after detection).
Enabled for everyone.
Pros:
- Unblocks any users that need extra dependencies
- Users that need it have it right away
- No need for allowlist implementation
Cons:
- We enable installing any package from anywhere to everyone potentially welcoming non-opensource code to run on toolforge
- Images will be bigger (we currently have 1G limit per tool set on harbor, so will not be bigger than that).
Option 3
Allowing only selected buildpacks for specific libraries, and not the "apt" buildpack.
E.g. this buildpack adds a bunch of additional libraries https://github.com/heroku/heroku-geo-buildpack
Many buildpacks can be found online, and we could create more ourselves.
Pros:
- More control on what people can install in their images
- Might be solved the same way that multistack/specific buildpacks would be
Cons:
- We would need to add those buildpacks individually, as people request them
- Some libraries might not be available as a buildpack, and creating a custom buildpack is possible but not easy
Option N
Add your options here!