dont automatically rewrite the .env file

[teto]

In https://github.com/rest-nvim/rest.nvim/pull/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]

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]

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]

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]

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