Change Details

Currently we don't provide anything specific for users to be able to connect to the different toolforge APIs This would be different to implement in both, the pre-build images and buildservice generated ones. === Pre-build images === * Install the packages always: sounds ok to me, would mean that we have to regenerate the images whenever we release a new package * Let users install them per-environment (not sure it makes sense), this is easy for python (pip install) but other langs might not be doable (we would need to provide many bindings) === Buildservice === * Install the packages always and automatically: ** Using a specific buildpack ** Hardcodding it inside the apt-buildpack somehow - probably not as it only triggers with Aptfile * Let the user specify the packages in the Aptfile - this means enabling toolforge repos, or passing them inside the Aptfile somehow

Currently we don't provide anything specific for users to be able to connect to the different toolforge APIs This would be different to implement in both, the pre-build images and buildservice generated ones. === Pre-build images === * Install the packages always ** Would mean that we have to regenerate the images whenever we release a new package ** Should be easy to add them * Let users install them per-environment (not sure it makes sense), this is easy for python (pip install) but other langs might not be doable (we would need to provide many bindings) ** We don't have a nice way of doing this (having single-binaries would help) === Buildservice === * Install the packages always and automatically: ** Using a specific buildpack *** Might still require us building ubuntu packages *** We might be able to workaround with venvs + scripts *** If we had single binary deployments this would be way easier xd ** Hardcodding it inside the apt-buildpack somehow - probably not as it only triggers with Aptfile *** Same as the next point * Let the user specify the packages in the Aptfile ** This means enabling toolforge repos (easy) ** This will require rebuilding the packages for ubuntu jammy + expose the repository (a bit more troublesome)

Currently we don't provide anything specific for users to be able to connect to the different toolforge APIs This would be different to implement in both, the pre-build images and buildservice generated ones. === Pre-build images === * Install the packages always: sounds ok to me, would mean that we have to regenerate the images whenever we release a new package ** Would mean that we have to regenerate the images whenever we release a new package ** Should be easy to add them * Let users install them per-environment (not sure it makes sense), this is easy for python (pip install) but other langs might not be doable (we would need to provide many bindings) ** We don't have a nice way of doing this (having single-binaries would help) === Buildservice === * Install the packages always and automatically: ** Using a specific buildpack *** Might still require us building ubuntu packages *** We might be able to workaround with venvs + scripts *** If we had single binary deployments this would be way easier xd ** Hardcodding it inside the apt-buildpack somehow - probably not as it only triggers with Aptfile *** Same as the next point * Let the user specify the packages in the Aptfile - this means enabling toolforge repos, or passing them inside the Aptfile somehow ** This means enabling toolforge repos (easy) ** This will require rebuilding the packages for ubuntu jammy + expose the repository (a bit more troublesome)