-
-
Notifications
You must be signed in to change notification settings - Fork 148
dont automatically rewrite the .env file #180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A request from my own workflow would be that the set variable would work across buffers and is accessible until neovim is closed.
Raw writing to a file is available already as part of the global lua environment. For example, the following creates and writes "hello world" to a file:
So I don't know if it is necessary to add an extra field to the context table with this ability. However, as you mentioned in #122, it would be very good to have the option to choose whether "set_env" persists to the currently selected env file or just to memory. You also mentioned, in #122, an interface like:
This solution would work well for my work flow. And if we changed "value" to be any type not just string then it would cover this issue as well. How would something like that work for your workflow? |
or just provide different variable context: persistent-context (with an autosave to file option to mimic what is available), or a buffer-based temporary context (my use case is testing a CRUD scenario where I post -> get -> put -> get -> delete but dont care about the resources, I just need to retreive the generated IDs on post/put) |
Hello, I just realized that In most of our project's we rely on docker compose which also uses |
Closing due to v3 release. |
Uh oh!
There was an error while loading. Please reload this page.
In #122 we merged support for env session
the current behavior is that on any variable change, the .env file is regenerated which I find very annoying.
Rewriting the file discards commits an the structure, plus in case of failure it can destroy the file. I tend to think that .env are often not (git) versioned due to their dynamic nature so losing that file can be surprising as well as undesired.
As I develop on rest.nvim, this happens quite often to me.
The ability to save a run to a file is enticing but I think we should let the user be the master of that in a
One problem too is that set_env only accepts strings so far, as the variable will be serialized at some point, while for my tests, I would like to add any type of variable to the context.
The context could be buffer-local and shared between requests of a same buffer.
cc @D-James-GH
The text was updated successfully, but these errors were encountered: