godotenv multiline env vars and unexpected tokens #6
Labels
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/go-abra#6
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While learning/testing
abra app ls
I ran into the issue mention in with multiline env vars. The following diff seemed to work, pointing to the mentioned fork temporarily. A few env files have multi-line requirements, so it seems we need this.Also, I raised https://github.com/joho/godotenv/issues/150 for another issue. Maybe we need to publish a patch to fix this also?
Godotenv seems quite nice but also kinda buggy. Don't see any alternative right now.
Oh wait, https://github.com/spf13/viper also supports
dotenv
format... however, it doesn't support multi-line env vars 😢 I see they are using the underyling https://github.com/subosito/gotenv library which would have to implement multi-line support too.I wonder is this a sign to migrate to YAML? I was able to parse the following using viper:
This may be going on a total tangent but I could imagine we could re-work some of the format of the
.env
file to be less confusing and based on bash-isms? For example, how secrets are managed.From our Gitea configs:
Could be:
Which would be more intuitive since you use those names in the
compose.yml
file. Then we could change lines likename: ${STACK_NAME}_db_password_${SECRET_DB_PASSWORD_VERSION}
to something less verbose likename: ${DB_PASSWORD_SECRET}
because we have more programmatic control on the loading?We had originally went with env format because it was easier but maybe it is worth reconsidering this now?
I think moving to Viper and then doing what makes sense for the situation is the best way forward sindi it seems to support everything. I will move it to Viper and then we can work on the config later.
Out-band-logs lead to a switch to koanf due to:
I consider this fixed for now with
0242dfcb0f
. Wanna make sure I am not jumping the gun on that. When it comes to like what to do with dealing with apps .env files I think we can make a new issue for this if thats ok with you @decentral1se?💯
@decentral1se @roxxers I think I'm sold on the benefits of YAML -- the one thing we'll lose is the ability to pick up the config files using vanilla Docker, because AFAIK Docker only supports env files.
Maybe we don't need to give as much assurance to folks for the "whoops Co-op Cloud disappeared" situation now that we're becoming more of a thing? But if that still does feel useful, maybe the solution is a new command that can export an app config in env format?