gnoland start --config flag is tied to the flag configuration and not the node config

[zivkovicmilos]

Description

The configuration flag value specified in the gnoland start command:

gno/gno.land/cmd/gnoland/start.go

Lines 113 to 119 in 52ea535

	fs.StringVar(
	&c.config,
	"config",
	"",
	"config file (optional)",
	)
	}

is actually tied to the ffcli config (flag configuration for the gnoland start command), and not the node configuration:

gno/gno.land/cmd/gnoland/root.go

Line 29 in 52ea535

ff.WithConfigFileFlag("config"),

[thehowl]

Shall we change it and make it tied to the node config file?

This way we could also compromise on the "scriptability" Antonio was worrying about. ie. we can run gnoland like this:

gnoland -config /dev/stdin << EOF
config=file
values=1
EOF

[moul]

To maintain consistency with other command-line interfaces (CLIs), I propose the following approach:

• Keep the flag "-config" as the general configuration file.
• Embed the TM2 config and prefix all its components.

type opts struct {
    Verbose    bool
    OtherFlag  string
    TM2Config  tm2config.Config
}

Then, register flags using the prefix --tm2-. This approach preserves the current behavior of manually configuring files while providing the option to patch them using flags. By adopting this method, we ensure consistency across your CLIs.

You can find more details about this approach in the description provided in issue #731.

[moul]

Another approach is to introduce a gnoland init function that handles the customization (creation or patching) of the configuration file.

Subsequently, the gnoland start command can utilize the existing LazyLoadOrCreate method, which would render gnoland init optional, unless you intend to personalize your node.

[zivkovicmilos]

@moul

I am on the fence about this, because I support both of the approaches you've mentioned.

I've always utilized specific flags for node configuration, along with support for a config file (you have the file -> env -> flags precedence here, or whatever the order is). The thing I dislike about this approach is that you insanely bloat the start command, which should be mega simple, while giving the user power to configure.

What do you think about this, as a compromise:

• introduce a command suite for generating the node config and modifying it (we don't have this now)
• make gnoland start take a --tm2-config flag, that is the path to the configuration. If no configuration is provided, the one from the current working directory is loaded (or a default one is generated and loaded). This last part details how we currently have the config file for the node working

[zivkovicmilos]

I will open up a PR for implementing this fix, since it's blocking us on some efforts