Skip to content

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

Closed
teto opened this issue Jan 23, 2023 · 4 comments
Closed

dont automatically rewrite the .env file #180

teto opened this issue Jan 23, 2023 · 4 comments

Comments

@teto
Copy link
Collaborator

teto commented Jan 23, 2023

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

{% 
context.write_to_file ...
%}

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

@D-James-GH
Copy link
Contributor

A request from my own workflow would be that the set variable would work across buffers and is accessible until neovim is closed.
My main use for the set_env is to save my access token from the response of "/auth". I then use this in the header of all other requests.
For my workflow I would also need the value of whatever I set to be available when rest.nvim is inputting variables so that the following works:

GET {{base_url}}/posts
Authorization: Bearer {{access_token}}

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:

GET https://jsonplaceholder.typicode.com/posts/1
Content-type: application/json

{%
local file = io.open("test.txt", "w")
file:write("Hello World")
file:close()
%}

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:

{% 
context.set_env("some_key", "value",  "write_flag (defaults to false)")
%}

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?

@teto
Copy link
Collaborator Author

teto commented Jan 26, 2023

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)

@gautaz
Copy link

gautaz commented Jun 7, 2023

Hello, I just realized that rest-nvim was poking in our projects' .env files so I cannot agree more that this should be a user's choice.
The default setting should be opt-in to avoid the user being taken off guard.

In most of our project's we rely on docker compose which also uses .env.
In this particular context, the .env file is shared between developers and is hence tracked by git.

@boltlessengineer
Copy link
Contributor

Closing due to v3 release.
Now rest.nvim can only read from .env files. It won’t update the file content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants