-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC - Package metadata #498
Comments
First opinion:
|
For "What" maybe the following adds
Will the convention be to keep all the documentation/readme information for a package on GitHub as the source of truth? Otherwise perhaps that should be captured as well. |
Idiomatic go is the best for me. You can just add on top of the package or in separate file a comment note like it is done for BUG etc in the doc. MARKER(uid): note body // Package example is an example package.
//
// GNO(publicationDate): xxx
// GNO(publishedBy): yyy
// GNO(publicationPath): zzz
package example |
The way I see it we should extend
We could potentially restrict Most importantly this means that we can have the default behaviour for As for the other tags, I think they are either potentially harmful or redundant (we should include what is important for machine tools to parse - and avoid information which can be obtained by some other more canonical way, as otherwise the package author has to keep the data in sync).
|
Do we still want this? I don't think we want this. |
We will want to have some metadata for packages shown in Question is, will this data be parsed directly from the chain, or in some other way? |
At some points, we'll want to attach metadata to packages.
Right now, I can see three categories of metadata:
version
,isForkOf
,parentVersion
,gitRepo
,gitSha
,contact
, etcpublicationDate
,publishedBy
,publicationParameters
,publicationPath
, etcisLatest
,isDeprecated
, etcThis issue is to discuss the what, how, and when.
What
What metadata is useful/useless?
What should be required/optional, and what could be sane default values?
How
Should we add a
package.json
or equivalent?Should we extend
gno.mod
?Should we use idiomatic go with comments?
Should we make the metadata callable from another contract?
Should we rely on indexers to make the magic and keep the chain minimalist?
When
As soon as we know where we're going, let's try to find the best first step and, ideally, a stakeholder that would require the feature.
The text was updated successfully, but these errors were encountered: