Enhancement: Defaults for packages rather than building augmented images about whalebrew

[terev]

This would allow decoupling the labels from their actual image. Allowing new images to be used but the package would still work with whalebrew because of these defaults. Labels on actual images could be treated as overrides.

[terev]

@tjamet any thoughts about this idea? I haven't flushed out the details but I'm curious hear opinions about if it's even reasonable.

[tjamet]

I am wondering how would this look like, how to know what is the "package" image to use for a given "program" image.
I fear that de-coupling both may introduces some complexity we could avoid.

It looks like being able to run whalebrew install whalebrew/gawk --use-image mor1/gawk

Also wondering about the problem to solve. Are we trying to ensure images are kept up to date so we can benefit the latest version, always?

[terev]

The problem this is trying to solve is avoiding having to build encompassing images for a given base image in order for it to be supported by whalebrew. If solved this would allow tags of any given image to be used as long as there's an associated whalebrew config for it.

When installing an image like whalebrew install wget whalebrew could check the whalebrew image repository for an image with the same name (whalebrew/wget this image could just contain the labels) then pull and inspect it to use the labels as defaults. It would also be nice as you pointed out to be able to tell whalebrew an image to use as the base config. It would also be possible to make where to look for these configuration images configurable via the whalebrew config file.

[terev]

For example node has images for a lot of releases of the cli tool but whalebrew only has one supported tag latest.

[tjamet]

I am seeing there multiple points that we could handle separately.
First is the ability to use a different image for a given package.
This is a pretty nice feature IMHO, which is already supported by installing an image and then editing the installed file whalebrew edit wget in our case. This is not as user friendly as it could be and we can indeed take an action on it to improve the UX.

On top of that, there is the reasoning about package and image to be used. I know that we are currently short in supported versions of images to be used, and hence require to tweak the settings to be able to install latest versions of several tools. Though, the model that we have currently (packing the tool together with the configuration) allows us to ensure that the package works correctly with the tool, and manage easily breaking changes. This is a quite common case in the packaging world, from Debian packages to homebrew, versions are pinned in the packages. Breaking this would make us face the package/program matching problem on our side, which I am unsure we want to get in. Instead, I would prefer to invest in improving the packaging to provide a wider range of versions, and checking that the packaging actually works.
I do have some ideas on the matter, I will try to come up with them shortly.

The last point is about matching the package and the program depending on the image name. I am unsure this needs to be performed automatically at the whalebrew level. Whalebrew could provide helpers for humans to do so, allowing them to check that both packages are actually installing the same program, not injecting malware, ... so we can have eventually have insights through issues and proposals on how users actually uses the feature and propose something that fits with the common usage.

[terev]

Pls disregard my previous edits of this comment. Your suggested solution for the --use-image flag seems like a great ux improvement.