A thing that came up is something we've talked about many times before... which is "what is dev mode". My original concern in https://github.com/DefangLabs/defang/issues/449 was that it would be nice from a development workflow perspective to be able to have "throwaway" values in your compose file (PASSWORD=password) for example, and then override that with "real" values (which may need to be secure/sensitive) in different environments.
After talking about it, I have come back to that conclusion, personally: if I went through the effort of explicitly specifying an encrypted value in a given environment, it should probably override the insecure, plaintext value. As I think through it, my reasoning is the following: the compose file is a general structure, but each deployment is more "specific" in that it will take things like mode, etc. into account when deployed. As such, the config vals are part of the more "specific" context, which should override the more "general" ones.
There are weird things that come up, though, when talking through this stuff and differences in how things are handled in the cloud vs local. So I was thinking (and stuff similar to this has come up in the past) that we should have a defang dev "prefix" (or maybe it's a defang --dev global flag, but it would be nice to have two fewer characters to type).
What I'm suggesting is the following: you should be able to run any normal defang command with the dev prefix, and we should have a local version of that.
For example defang dev config set PASSWORD=potatoes would:
check if we have a compose.dev.yaml file and if not, generate it with the standard that we're currently using (this would happen with any invocation of a command under defang dev
check if we have a .env.dev file and create it if not
write PASSWORD=potatoes in a .env.dev file (or update the value)
If you then run defang dev compose up it would, under the hood, invoke docker compose --env-file=.env.dev -f compose.dev.yaml up
We could do the same with logs, etc. just proxying through to the docker commands (using the sdk or otherwise).
The idea is essentially that by prefixing with dev we're sorta saying --provider=local and you should be able to do anything you do in the cloud on your own machine.
Prakash-Sundaresan
commented
1 month ago
Just had a good chat with @nullfunc about config, interpolation, etc. where we talked about stuff like this: https://github.com/DefangLabs/defang/pull/682#discussion_r1767890413
A thing that came up is something we've talked about many times before... which is "what is dev mode". My original concern in https://github.com/DefangLabs/defang/issues/449 was that it would be nice from a development workflow perspective to be able to have "throwaway" values in your compose file (
PASSWORD=password) for example, and then override that with "real" values (which may need to be secure/sensitive) in different environments.After talking about it, I have come back to that conclusion, personally: if I went through the effort of explicitly specifying an encrypted value in a given environment, it should probably override the insecure, plaintext value. As I think through it, my reasoning is the following: the compose file is a general structure, but each deployment is more "specific" in that it will take things like mode, etc. into account when deployed. As such, the config vals are part of the more "specific" context, which should override the more "general" ones.
There are weird things that come up, though, when talking through this stuff and differences in how things are handled in the cloud vs local. So I was thinking (and stuff similar to this has come up in the past) that we should have a
defang dev"prefix" (or maybe it's adefang --devglobal flag, but it would be nice to have two fewer characters to type).What I'm suggesting is the following: you should be able to run any normal defang command with the
devprefix, and we should have a local version of that.For example
defang dev config set PASSWORD=potatoeswould:compose.dev.yamlfile and if not, generate it with the standard that we're currently using (this would happen with any invocation of a command underdefang dev.env.devfile and create it if notPASSWORD=potatoesin a.env.devfile (or update the value)If you then run
defang dev compose upit would, under the hood, invokedocker compose --env-file=.env.dev -f compose.dev.yaml upWe could do the same with logs, etc. just proxying through to the docker commands (using the sdk or otherwise).
The idea is essentially that by prefixing with
devwe're sorta saying--provider=localand you should be able to do anything you do in the cloud on your own machine.