search

nats-io / nats-architecture-and-design

Architecture and Design Docs
Apache License 2.0
177 stars 20 forks source link

[adding] ADR-21 NATS Configuration Contexts #80

Closed ripienaar closed 2 years ago

ripienaar commented 2 years ago

Signed-off-by: R.I.Pienaar rip@devco.net

ripienaar commented 2 years ago

Let's discuss Q1 22. It's a great feature, we just need to determine where it'll be implemented.

👍 for now this is just capturing the feature, not communicating an intent for clients to implement.

tbeets commented 2 years ago

In sample usage API, the value of OS environment variable would be the filename of the desired context or the friendly name of the desired context? Both options would seem useful. @ripienaar

ripienaar commented 2 years ago

In sample usage API, the value of OS environment variable would be the filename of the desired context or the friendly name of the desired context? Both options would seem useful. @ripienaar

No file name based access - its just the context name. In future we'd have non file based context storage, so its only name.

The CONTEXT in the example is essentially equivelant to --context in the CLI

tbeets commented 2 years ago

LGTM. I think whether we factor in more NSC stuff entirely related to futures of CLI tools (i.e. what and how many).

derekcollison commented 2 years ago

I think this direction and exposing this to apps and scripts and automation is spot on.

One observation I have had is that a bunch of popular tools just own ~/.<proj>, so for us would be ~/.nats maybe.

ripienaar commented 2 years ago

One observation I have had is that a bunch of popular tools just own ~/.<proj>, so for us would be ~/.nats maybe.

That's the nice thing about standards, we can just follow the it without thinking what some others tools or dont. The standard covers everything from local data storage, binaries and more - storage paths for example that we need for things like nats server run and integrates with the eco system at large.

Why would we choose something that specifically would work against the desktop os direction?

derekcollison commented 2 years ago

My $0.02 is that default standards outweigh the formalized ones, who continually seem to be losing power. So wanted to see what the popular projects with lots of users were doing. I will check if anyone uses that convention today or if they have noted they would switch, but I am not aware of any. Are you?

ripienaar commented 2 years ago

It has VERY WIDE adoption. Few kind of small projects like Emacs, curl, git, GTK, helm, ImageMagick, less and a pile of standard shell things, every linux desktop environment, systemd and its dynamically mounted home directories, mercurial, mutt, nano, neovim, python pip, tmux, etc.

derekcollison commented 2 years ago

Good to know. Been using emacs forever so it is still ~/.emacs for me. A bunch of the other ones as well, but maybe new installs default to `~/.config/<project>

ripienaar commented 2 years ago

Yes, obviously backwards compat on tool like the listed ones is fairly important, but the gravity is towards this. Emacs checks ~/.config/emacs in adition to older paths.

tbeets commented 2 years ago

I see about 50/50 sticking their stuff under ~/.config by default. JetBrains, Google Chrome, and NATS CLI are three examples that do. Rust, Mozilla, Maven, minikube, AWS, Azure, and NSC (!) are examples of those that splat in the homedir. Lots of variability.

tbeets commented 2 years ago

Definitely support sticking application-specific stuff under ~/.config to separate from typical shell config etc. in homedir if we have to make a default location call either way.

ripienaar commented 2 years ago

Arch wiki has a partial list of things that supports it https://wiki.archlinux.org/title/XDG_Base_Directory#Supported