generated .env file stored in current directory

[jonassmedegaard]

Running command atomic-server setup-env stores a file with a specific name in current directory.

I find that a bad default behaviour. There is a real risk of "littering" - i.e. forgetting about a generated file when standing somewhere random while issuing the command.

Please consider by default to emit that content to STDOUT, and introduce an optional argument --file to redirect to a file.

[joepio]

Hmm, when would this littering + forget scenario occur? The command is pretty explicit in that it creates a .env file in the current directory. Or should I rename the command to something like setup-env-file?

When would you prefer STDOUT as a user? I can't imagine a scenario for this, personally.

[jonassmedegaard]

Please follow conventions of classic BSD or GNU tools unless you have a strong need to do differently.
As an example, here is some parts of man logger which I guess is also available on MacOS:

When the optional message argument is present, it is written to the log. If it is not present, and the -f option is not given either, then standard input is logged.

-f, --file file
Log the contents of the specified file. This option cannot be combined with a command-line message.

[jonassmedegaard]

when would this littering + forget scenario occur?

Always :-)

I could turn it around: When do you ever need to create a dot-file in current directory? You would only ever need it when you happen to stand in the root of a $HOME directory, where (conventionally) dot-files are stored.

On a related note: using hidden files (i.e. classic dot-files beginning with a dot) is nowadaysdiscouraged and commonly replaced with non-hidden files below dot-folder .config as per XDG FHS standards.

[jonassmedegaard]

What might make sense is to create the file at a well-defined path (and auto-create path directories if not existing, and fail if file already exist and some --force option was not passed).

But is this really a config file? Seems to me more like a systemd env file - which is just one way out of several to pas options to a session, and therefore no default path is sensble, and therefore no path should be used by default: Emit to STDOUT by default (not to current directory!).

[jonassmedegaard]

(please imagine an "in my opinion" to all of my posts - you are of course welcome to do however you please with your project)

[joepio]

Thanks for sharing your thoughts on this. I fully agree that following conventions should be the default, but I'm not sure if there's a convention for creating .env files. Most developers will need to use the .env in there folder where they run atomic-server - that's where the .env file is read by default, so I still think outputting in the current dir is the way to go.

What might make sense is to create the file at a well-defined path (and auto-create path directories if not existing, and fail if file already exist and some --force option was not passed).

That's not what .env files are for - they are highly coupled to directories, they are local.

That's why non-local things are stored in theconfig.toml that lives in the ~/.config/atomic folder.

But all of this is confusing, and not ideal. There are .toml files, CLI flags, ENV options... Clap allows me to use all of these, but still it feels confusing.

[jonassmedegaard]

Most developers will need to use the .env in there folder where they run atomic-server - that's where the .env file is read by default, so I still think outputting in the current dir is the way to go.

How do you know that most users are standing in the same directory as their atomic-server binary considers $HOME?

I mean, if I do sudo -u _atomic atomic-server then $PWD is most likely not the $HOME of atomic-server but wherever randomly I am at when I execute that command.

[jonassmedegaard]

What might make sense is to create the file at a well-defined path (and auto-create path directories if not existing, and fail if file already exist and some --force option was not passed).

That's not what .env files are for - they are highly coupled to directories, they are local.

Let's maybe start at the beginning, then: What is .env files for? Your own help output states that .env files "shows various options that you can set".

If the purpose of .env files is to show options that can be set, then please show it on screen (i.e. on stdout) not save it into a hidden file.

If the purpose is not what you document, but instead what I guess - namely to be parsed by systemd service unit, then please save it at a deterministic path because systemd does not normally load such files from "current working dir" but from explicitly declared paths - see man systemd.exec at section ENVIRONMENT.

If the purpose is something third then please document what that purpose is, and we can restart this conversation then, when we both know what we are talking about...

[joepio]

Let's maybe start at the beginning, then: What is .env files for?

The .env is used for when you run atomic-server, as is, in some directory. This is a pretty typical VPS scenario, I believe.

Basically, I think most devs will like following these steps:

cargo install atomic-server
# Generate .env file in current dir
atomic-server setup-env
# User modifies some settings
vim .env
# Server reads local `.env` 
atomic-server

If the purpose of .env files is to show options that can be set, then please show it on screen (i.e. on stdout) not save it into a hidden file.

Well, showing isn't the purpose anymore (that was its original purpose indeed, but has changed since clap 3.0) - that's what the --help is for - that shows all options that you can set. But, instead of passing these as flags, you may want to use ENV vars. And these are automatically read from the .env in the folder where you're running atomic-server.

If the purpose is not what you document, but instead what I guess - namely to be parsed by systemd service unit

Not typically, at least not what I thought. As you know I'm pretty new to systemd (see) #271