Envprofile auto-set in all console commands

[radutopala]

Envprofile should be transmitted automatically, somehow, to all Console commands.

This way we can avoid adding

        console.StringFlag{
            Name:  "envprofile, e", // long and short posix flag name
            Value: aah.App().Config().StringDefault("env.active", "dev"),           // default flag value
            Usage: "Environment profile name to activate (e.g: dev, prod)",
        },
    },

to every command.

The commands are part of the built binary, so it makes sense to have the envprofile in all commands as well.

A solution would be to append the EnvProfile StringFlag to Flags, when the command is added in init.

[jeevatkm]

@radutopala Thanks for bringing up the suggestion for framework improvements.

I understand your proposed solution to add envprofile flag to all the commands implicitly. I'm wondering, does every command will be in the need of this flag? How to disable/remove this flag from particular command if aah user don't want it on the command?

I will do my homework and get back to you.

[jeevatkm]

@radutopala I think, solution could be having a config to add envprofile flag into commands.

# Application binary console command's configurations.
console {
  # Convenient application binary flags configurations.
  flags {
    # Flag `envprofile`
    envprofile {
      # Add command/subcommand names into list to enable flag envprofile.
      # Framework would initialize app configuration based on flag `envprofile` input
      commands = ["cmd1", "cmd2", "cmd1.subcmd1", "cmd2.subcmd2"]
    }
  }
}

Please have a look and let me know. I will schedule it for v0.13.0 release.

[radutopala]

@jeevatkm And these config defined flags will be auto-set also in the root command?

Even so, I don't think it's really necessary to have this level of abstraction. You would then need to be able to set different params in this configs entry for each flag, which I think should be done in code instead.

envprofile is already set in the root command by default. And the root's subcommands should have access to the same envprofile, because these subcommands are within the same app, the same context.

I think we just need a very simple solution here 😄just append the envprofile flag to all root's subcommands.

[jeevatkm]

@radutopala Okay, lets start with simple design and could be improvised in the future.

Solution is -

Add envprofile flag into command when aah user register into application via aah.App().AddCommand(...). Initialize the app configuration based on the flag input and make available to the command.

[goku321]

Can I take this up?

[jeevatkm]

@goku321 yeah, you're welcome. Give it try, as you will be learning the framework internals. It would provide good path for your future contributions too.

[goku321]

Thanks @jeevatkm :)

[jeevatkm]

@goku321 how are you doing? Thought to check with you, I hope you’re learning and progressing. Please let me know if you need any assistance.

[goku321]

@jeevatkm Thanks for checking on me. In the excitement I took up a lot of open source tickets in parallel and that's why there's a delay from my end. I am clearing the backlog one by one. Give me a couple of days to get back on this. I am really interested and looking forward to contribute to this framework. Thanks for your patience.

[goku321]

Hi @jeevatkm I have a question: Do I need to add envprofile flag within initCli method inside commands.go just like help flag?

[jeevatkm]

@goku321 I'm sorry for the delayed response. As I have communicated in #262, i"m trying to release v0.13.0 version as soon as possible and work on v0.14.0 revamping aah framework design.

So I have implemented this option. Thank you for help and looking forward to your further participations.