Add environments to group related variables

[rodweb]

Hello,

First of all, thanks for the great package! It's been a pleasure to work with it.

To give you some context, I'm coming from Postman, which has the concept of Environments to manage sets of related variables.

The most common use case is having a different set of values for development and production.

So I'd like to introduce the concept of environments to verb-mode.

I made a simple minor mode for myself to test it out and I'd be willing to make a proper PR if you like the idea.

[federicotdn]

Hi @rodweb, that is a cool idea, it would be great to have something like this integrated directly into verb-mode.

Some thoughts:

• We could add all this directly into verb-mode, without having to add a separate minor mode.
• There should always be an environment selected. It could be named "default", or something similar. This should simplify the code a bit, because we can assume there is always an environment to use. Your code does something similar to this, but the default environment is modeled separately there.
• Your scripts stores environments using a defcustom. This would imply that the environments are shared across all Verb files in use. However, I can imagine certain Verb files using certain variables, and other using others. In this case, I think it would make more sense to make the list of environments a buffer-local variable. The values could be initialized by some Org property defined at the top of the file. What do you think? Would this option be less useful for your use case?

[rodweb]

• Yeah, no need for a minor mode.
• Do you mean like setting verb-environments to '(("default" . nil) by default?
• Not sure I follow this one. I'll put some code as a reference bellow.

(use-package verb-env
  :straight (verb-env :host github :repo "rodweb/verb-env" :branch "main")
  :hook (verb-mode . verb-env-mode)
  :custom
  (verb-env-default "development")
  (verb-env-environments '(("development" . ((api-url . "http://localhost:5000/")
                                             (api-token  . "dev-token")
                                             (elasticsearch-url . "http://localhost:9200/")
                                             (elasticsearch-index . "dev_index")))
                           ("production" . ((api-url . "https://api.com/")
                                            (api-token . "prod-token")
                                            (elasticsearch-url . "http://localhost:9300/")
                                            (elasticsearch-index . "prod_index"))))))

For example, do you mean having just api-url and api-token as Org properties for the API Verb file? If so, I like the idea. It would be cleaner than what I have now. But I'm not sure how I'd specify values for multiple environments though.

[federicotdn]

What I mean is: By setting the verb-env-environments, you are effectively creating a set of environments that are shared among all .org files you open. I can imagine that in some cases, some environments would not be applicable to some files: for example, if I am working on two APIs, Foo and Bar, and each one has a development and production environment (for a total of 4 environments), then you would never use the Foo environments when you open the file for Bar (because the values themselves wouldn't make sense, and even the set of variables names could be different).

For this reason, I imagined that then it would make sense to define environments per file. What mechanism we could use for that, I am not sure, but obviously we could discuss it.

However, if you find that the workflow of having a set of environments that are accessible/usable from any .org file useful and productive, I say we go for it! In that case, I would take back what I said about the default environment. It would be better to allow users not have to define a default one, and just handle the case of no environment activated manually.

I have a usability question though: if I activate an environment that defines a variable foobar, and then I set that variable via verb-set-var, would it just write the variable to the buffer-local variables I'm using, or also actually write the variable back to the environment I activated?

[rodweb]

For this reason, I imagined that then it would make sense to define environments per file.

For my current needs, I'd rather have it set per file too.

I have a usability question though: if I activate an environment that defines a variable foobar, and then I set that variable via verb-set-var, would it just write the variable to the buffer-local variables I'm using, or also actually write the variable back to the environment I activated?

It would be nice to have an interface like org-set-property to write back, but I can see this behaviour being a defcustom too.

[federicotdn]

I currently do not have the bandwidth to tackle this, however PRs are welcome of course.