META gnomod.toml

[moul]

The foundation for gnomod.toml is done in #4331.

It gives us structured package-level. This metadata will let us control visibility, running constraints, versioning(?), and usage policies for packages. It’s especially urgent for cleaning up the examples/ folder ahead of launch.

Needed now:

To proceed with examples/ cleanup for launch, we need to implement private and draft flags (https://github.com/gnolang/gno/issues/4370):

• draft=true: can be deployed at genesis, but not with addpkg, can be imported by other genesis packages, but not by newly added one
• private=true`: cannot be imported or state-persisted externally

Can be done later

• Support upload_metadata.uploader in lazy genesis for use with std.PrevRealm in init(). (https://github.com/gnolang/gno/issues/4371)
• Port/fix gno mod graph to work after #4331
• Add replace directive support (https://github.com/gnolang/gno/issues/2601)
• Consider versioning/deprecation fields
• Improve gnoweb display based on package metadata
• Improve docs/supports/examples
• Completely deprecate previous gno.mod file after a grace period
• Refactor pkg/gnomod to remove the previous `xxx_pkg.go part of the package
• Consider other fields (see https://github.com/gnolang/gno/issues/498)
• Support comments and arbitrary order (currently replaced when remarshaling)

Related https://github.com/gnolang/gno/issues/2904

[thehowl]

drafts

These should also not be state-persistable by non-drafts, no?

• Improve gnoweb display based on package metadata

So do you think this should be a part of the gnomod.toml, or should gnoweb have its own config file?

Personally I actually think that a [gnoweb] section (which is actually ignored by our gnomod parser) would be better.

---

The overall plan makes sense

[moul]

These should also not be state-persistable by non-drafts, no?

No, that's okay. We’ll have a collection of contracts that work together, and they all need to be marked as draft.

So do you think this should be a part of the gnomod.toml, or should gnoweb have its own config file? Personally I actually think that a [gnoweb] section (which is actually ignored by our gnomod parser) would be better.

I think gnoweb should read gnomod.toml for anything relevant to the chain or VM, like upload_metadata.uploader.

But we also want gnoweb-specific fields (e.g., theme = blue) that aren’t relevant to the VM or gno CLI.

I agree with your idea of having a [gnoweb] section in gnomod.toml, which the core tooling can ignore. That said, since we want to experiment more, I like the idea of a separate gnoweb.toml totally freeform and unvalidated. That way, we can manage it independently with something like maketx editpkgfile gnoweb.toml, without worrying about its impact on the chain (which only depends on .gno files and gnomod.toml).

So, my take:

• Let’s use gnomod.toml for any field that affects the chain or VM.
• Let gnoweb read from gnomod.toml when needed.
• For anything UI-specific, use a separate gnoweb.toml file that’s totally permissionless and easy to override.

Later on, we can reconsider merging both approaches. Or.. if we go with your [gnoweb] section idea now, we’d just need to ensure our TOML parser allows flexible schemas for that section, which also works for me.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Remove stale label or comment or this will be closed in 3 months.