Hi, is there any chance that merge request related to https://github.com/authzed/spicedb/issues/1082 would be reviewed / merged soon?

left some comments on the PR

To make it clean: do you suggest to drop

.env

and

.env.local

and others, and load values only from

./spicedb.env

?

the main suggestion is to use

viper

, companion library to

cobra

, as we already use both and should support env files. w.r.t to hierarchies of files, I couldn't conclude there is a unanimous convention around file naming, and I also wasn't sure if we want to load an

.env

file that could contain information relevant to other processes, hence I thought of a dotenv file specific to spicedb

I was picking Ruby [conventions](https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use) as referenced by [joho/godotenv](https://github.com/joho/godotenv#precedence--conventions). It is quite common and useful during development to add a gitignore-d local env file to override any defaults.

yeah I do not doubt of it's usefulness, I'm all for improving developer experience. As I mentioned, SpiceDB uses

viper

to manage configuration hierarchies, and I'd say we should stick to if we can implement the same with it (which apparently it should support). As for

.env

vs

spicedb.env

, I don't know if that's not a convention in the

dotenv

world, but what I want to make sure is that SpiceDB does not load environments that are unrelated to it. I could imagine folks using

.env

to store secrets from other services that then get loaded there. In containerized environments may not be a concern, but it could be in other execution environments. is using

<appname>.env

unorthodox within the dotenv convention?

Planned to implement, but stopped before the first line. When its about dev experience, we should take care for backward compatibility. Current docstring of [SyncViperPreRunE](https://pkg.go.dev/github.com/jzelinskie/cobrautil#SyncViperPreRunE) says: > SyncViperPreRunE returns a Cobra run func that synchronizes Viper environment flags prefixed with the provided argument. I don't want to extend the behavior or this function with loading an arbitrary file.

@jzelinskie ☝️

I'm totally fine with supporting the standard

.env

in another function called

SyncViperDotEnvPreRunE()

.

Thx, Ill modify it accordingly.

I can have a look tomorrow, but first thought that comes to mind is to clean up the prometheus singleton registry (by assigning a new empty instance to it at the beginning of the test)