Registry

[gedw99]

Hey @WillAbides

in https://github.com/WillAbides/bindown-templates/blob/main/bindown.yml the properties and the sources of the remote binary are conflated together .

maybe a registry is needed at a global level per machine ? Then things are DRY and extensible without getting too crazy . There is a balance.

The global registry can be a git server.

I am using nats Jetstream to keep all global and remote registries up to date so we could use that with bindown if your up for it. I could also write it as a plugin off otherwise.

It would mean that a binary or a registry value would be streamed to all laptops or servers instantly . So then as a user you know of it’s existence without the pull / push cycles. It’s all real time .

[WillAbides]

I see what you mean about the properties and sources being conflated. I would like a crisp and clear config file with only a few lines per dependency, but I also want to know exactly what will be installed by looking at the config file. In my mind the dependencies section of the config is the crisp and clear part while templates and url_checksums are the gory implementation details that can mostly be ignored, but I suspect most people won't see it the same as me.

I've considered a global cache directory, but I had not considered a global registry. I think it's an interesting idea. If we just want to clean up the config file, the registry could be something as simple as a cache of the config at a given url.

I'm not sure about having a streaming service set values outside of config files, but I also don't really know much about nats or jetstream, so I may be misunderstanding what you are proposing there.

[gedw99]

I see what you mean about the properties and sources being conflated. I would like a crisp and clear config file with only a few lines per dependency, but I also want to know exactly what will be installed by looking at the config file. In my mind the dependencies section of the config is the crisp and clear part while templates and url_checksums are the gory implementation details that can mostly be ignored, but I suspect most people won't see it the same as me.

I've considered a global cache directory, but I had not considered a global registry. I think it's an interesting idea. If we just want to clean up the config file, the registry could be something as simple as a cache of the config at a given url.

Oh this is a good idea. The registry lives at a global location so there is no shared state.

Nats can run as a leaf server and so will do the caching locally just by the nature of how nats works.

I'm not sure about having a streaming service set values outside of config files, but I also don't really know much about nats or jetstream, so I may be misunderstanding what you are proposing there.

it can be done using the nats cli and nats server with the bin down just calling the nats cli using the cmd.exe feature of golang to get going. I will make a mini concept prototype and put it on GitHub with a makefile. I will let you know the url when I get it working.