Add metadata field to Gopkg.toml; warn on unknown fields #506
Comments
|
What would be part of [project] and why is it likely to be added? I would prefer the top-level [metadata] field but I see the point to use project, as it would be awkward to have metadata outside of project as soon as it is introduced. So it boils down to the probability of a project field. And consider: if we chose [project.metadata] now, we lose the option to chose an alternative name for [project] later. |
|
Thanks for feedback!
The most immediate, functional need would be if we want to have Other members would include non-functional information common in other systems - names of authors, license, etc. Again, idk if we end up with that stuff, but there it is.
I'm not too worried about this one - I think
i think mostly, yes. Though there's a possibility (let's really hope not) version the format of the file itself. If we do that, then we'd probably want a different section for that information, to clearly delineate it from information that describes the project, as opposed to the file. I'm increasingly inclined towards using it because it seems like the safer, more future-proof thing to do. |
As part of #276, we want to be able to provide a bit of future-proofing against the likelihood that we're going to need to add more properties to the data in Gopkg.toml and Gopkg.lock (e.g. for #291).
To that end, we should take (yet another) note from Cargo, and
[project.metadata]field in Gopkg.toml, which should be ignored by the parser except to enforce that it's a map type.This may be a bit awkward, given that we don't have a
projectfield to start with. I'm going with that, though, because I think it's likely we'll end up adding one. However, if that's too much of a pain, I'd also be good with just having a [metadata] top-level field.The text was updated successfully, but these errors were encountered: