Adding a buildpack like https://github.com/kr/heroku-buildpack-inline to our stack might be an interesting way to implement this feature request. That solution would not readily support the use cases that use an existing buildpack, but it would provide tool maintainers with maximum flexibility with minimal overhead for building their own tools.

In T363033#10484455, @dcaro wrote:

I'm not sure about this one, this means that your buildpack would have to implement and keep up with the API https://buildpacks.io/docs/reference/spec/buildpack-api/, and our system be in sync with it.

In practice it would mean staying in sync with the single stack that is available which seems not too hard based on the current cadence of upgrading the stack.

You can always develop the buildpack for toolforge itself (it's more complicated, as you need lima-kilo or a dev environment to test it), specially if it's something that's going to be useful.

Is this is generic "you" or a very specific @bd808 "you"? I am not aware of any per-tool configuration possibilities for the stack in use at this time, but it would be great to learn that I just missed some documentation.

I think maybe the suggestion here is that I could put effort into implementing a custom buildpack and then have it added to the stack that all tools use. Is this something that could reasonably scale to all Toolforge maintainers who wanted to do more than current stack allows? What test for "going to be useful" would be applied? This option seems like it would have the exact same upstream API following issues as an in-repo buildpack, but maybe I am misunderstanding something about that concern?

In T363033#10485884, @bd808 wrote:

In T363033#10484455, @dcaro wrote:

I'm not sure about this one, this means that your buildpack would have to implement and keep up with the API https://buildpacks.io/docs/reference/spec/buildpack-api/, and our system be in sync with it.

In practice it would mean staying in sync with the single stack that is available which seems not too hard based on the current cadence of upgrading the stack.

I think you are underestimating the effort of learning how to, building, maintaining and keeping the buildpack itself up to date. It's up to you if you want to put in that effort, though I don't think most tool maintainers would want to go through that pain. If you are able to gather enough people interested, then feel free to reopen the task and we'll be glad to reconsider putting some resources on allowing anyone to bring their own buildpacks to the platform.

You can always develop the buildpack for toolforge itself (it's more complicated, as you need lima-kilo or a dev environment to test it), specially if it's something that's going to be useful.

Is this is generic "you" or a very specific @bd808 "you"?

It's a generic you, that includes @bd808 you (in this specific case).

I think maybe the suggestion here is that I could put effort into implementing a custom buildpack and then have it added to the stack that all tools use. Is this something that could reasonably scale to all Toolforge maintainers who wanted to do more than current stack allows?

It would not scale to all the toolforge maintainers no, my point is that we don't have any data that any other maintainers will want to spend the time and effort to go through the process or building their own buildpacks.

What test for "going to be useful" would be applied?

Interest from the community essentially (whatever that form that might have... )

This option seems like it would have the exact same upstream API following issues as an in-repo buildpack, but maybe I am misunderstanding something about that concern?

It would yes, though if the new buildpack is in the stack we maintain, will test it before any upgrade of the stack, and upgrade of tekton, and upgrade of k8s, and upgrade of any other buildpack we support that might interact with it, and upgrade of any other custom script we have to be able to run the buildpacks. Otherwise you'd have to do on your own.