Support default values for variables about dotnet-env HOT 13 CLOSED

Ok, your test cases are clear, thank you for that.

However, this goes back to what I said: why are you defining defaults in these .env files? As in, why is the default not in the application? Or separate config?

I hear you on your dev vs prod configs -- but as noted in the readme https://github.com/tonerdo/dotnet-env?tab=readme-ov-file#a-note-about-production-and-the-purpose-of-this-library I strongly discourage using .env files in prod. And if you are using them in dev, you should not need defaults because they should probably just be the same for everyone, and if you need any overrides, just add the env vars there.

As in, as a reminder, if you define an env var in the shell that is also in the .env file, by default loading the env file will use the system env var rather than the env file one. (This behavior can be changed with clobberExistingVars to force using the .env file and not any system env var.)

I really need a clearer, specific example of why you need this specific approach, and not any of the ones I pointed out, to support such changes, please.

from dotnet-env.

Hi!
That's ok
We found solution out of the library.
As I wrote before it is awesome. We using it now and plan to to use it in future

from dotnet-env.

I'm glad you appreciate it! :)

Can you elaborate on why you want a default in this context? What you should do is read env vars and, in your application, if they are missing, provide a default value there.

from dotnet-env.

Hi. Now I work on solution which validate service configuration. I use .env files to create private(development) and production configuration. In case of production configuration I should use environment variable instead of values because production had several global settings.
The default values will be used to check service production configuration in pipe line and for documentation

from dotnet-env.

@rogusdev Can I start to work on this feature?

from dotnet-env.

Sure, though I do not promise it will get merged. But if you show me more clearly what you are trying to accomplish, that will help us figure out what you need.

from dotnet-env.

Sure, though I do not promise it will get merged. But if you show me more clearly what you are trying to accomplish, that will help us figure out what you need.

Ok. I'll try prepare more detailed description why I need support default values

from dotnet-env.

The easiest approach will be to write 1+ test cases that you want to have pass that do not currently. Then we can discuss what those cases demonstrate and how best to achieve them.

from dotnet-env.

The easiest approach will be to write 1+ test cases that you want to have pass that do not currently. Then we can discuss what those cases demonstrate and how best to achieve them.

Hi @rogusdev! I add test cases in PR

from dotnet-env.

Hi.
We try to achive 2 main goals

1. Validate fullness of configuration
   For that we remove all defalts from code. And want to have defalts in .env file. How we do that se below

        builder.Configuration
#if DEBUG
            .AddDotNetEnvMulti([".env", "private.env"], LoadOptions.TraversePath().NoEnvVars().NoClobber())
#else
            .AddDotNetEnvMulti([".env"], LoadOptions.TraversePath().NoEnvVars().NoClobber())
#endif
            .AddEnvironmentVariables();

Working in dev mode we use private.env with sensitive data. To build in pipeline we use .env to validate fullness of configuration and if .env have no defaults value we should customize pipeline for evry service ((.
2. Reuse .env configuration for deploy. We ofcourse read the readme

As you can see we do not use .env file in prod. We generate configmap from .env and partialy overlap from Global ConfigMap.

I hope I gave enought information. If not I'll try to give more in aspect you interested for.

Thanks!

from dotnet-env.

Thank you again for your thorough responses. Your example clarifies things. I still suspect that there is a better way to work your architecture without this feature.

So to further clarify, can you explain how much, if any, overlap there is between private env and regular .env? And you use .env to generate your k8s config map, which I can understand, but then I'm not following how defaults fit into that. Are you saying that private.env has the values that need to be customized and .env has the values that are consistently shared?

Also, a broader question: are you planning on these .env defaults being included in config map generation somehow? Is that a feature already present in that process?

Basically, at this point, I strongly suspect that you should definitely not have defaults because that means something in your system setup process has failed. You are not using .env in prod, just using it in dev and to generate config maps. That means that you should either have all those defaults in your .env or private.env already, and if you want to override them (i.e. not use the default) then you should be setting the env var locally. If this is not the case, please explain why.

I do not want to increase complexity of the code or behavior in ways that would make this system harder to maintain and use, unless it is truly valuable.

from dotnet-env.

Sorry forget 3 aspect
3. Generate documentation. We want to generate documentation from .env files to markdown use comments to describe variable and default value to show default in documentation.

Return to your last comment

I still suspect that there is a better way to work your architecture without this feature.
If you have any idea hot to do it explain please

So to further clarify, can you explain how much, if any, overlap there is between private env and regular .env?
About 80% this used only on developer workstation. private.env NEVER go out from developer workstation now.

Config map generated from .env

apiVersion: v1
data:
  POSTGRES_HOST: ${POSTGRES_HOST:-localhost}
  POSTGRES_PORT: ${POSTGRES_PORT:-5432}
  POSTGRES_DATABASE: ${POSTGRES_DATABASE:-service-name}
  POSTGRES_USER: ${POSTGRES_USER:-service-name}
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize-(devel)
    app.kubernetes.io/name: service-name
  name: service-name-b5t66t6thb
  namespace: namespace-name

Global config map

apiVersion: v1
data:
  POSTGRES_HOST: test.organization.com
  POSTGRES_PORT: 5437
kind: ConfigMap
metadata:
  name: global-config
  namespace: namespace-name

When all config maps will apply to container. Data will be executed as environment variables. Execution order will be first global config, second service config. This need provide fair overlapping because service config have more priority than global. And envirinment will have following state

  POSTGRES_HOST: test.organization.com
  POSTGRES_PORT: 5437
  POSTGRES_DATABASE: service-name
  POSTGRES_USER: service-name

If no default in service config envirinment will have following state

  POSTGRES_HOST: test.organization.com
  POSTGRES_PORT: 5437

If I change load order it will be less clear for understand an have no effect because envirinment will have following state

  POSTGRES_HOST: test.organization.com
  POSTGRES_PORT: 5437

Ok. I can provide another service configuration

apiVersion: v1
data:
  POSTGRES_HOST: localhost
  POSTGRES_PORT: 5432
  POSTGRES_DATABASE: service-name
  POSTGRES_USER: service-name
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize-(devel)
    app.kubernetes.io/name: service-name
  name: service-name-b5t66t6thb
  namespace: namespace-name

With changed order (load service config first) it will be work. But in that case any one who whant to change for example POSTGRES_DATABASE should create full copy of service config to change 1 variable look dirty for me.

from dotnet-env.

Ah, I am very sorry, I forgot to reply!

Are you actually resolved regarding this at this point? I'd love to know what you are doing at this point: did you fork and add, or get swayed by my suggestions, or find a different library that has this feature?

from dotnet-env.