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

Add metadata field to Gopkg.toml; warn on unknown fields #506

Closed
sdboyer opened this Issue May 3, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@sdboyer
Copy link
Member

sdboyer commented May 3, 2017

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

  1. Introduce a [project.metadata] field in Gopkg.toml, which should be ignored by the parser except to enforce that it's a map type.
  2. Warn if we encounter any unknown fields in Gopkg.toml. This should help discourage unintentional use, and channel anything that users want to add into that metadata.

This may be a bit awkward, given that we don't have a project field 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.

@sdboyer sdboyer added the enhancement label May 3, 2017

@sdboyer sdboyer added this to the Manifest and Lock committable milestone May 3, 2017

@sdboyer sdboyer changed the title Warn on unused fields in Gopkg.toml Add metadata field to Gopkg.toml; warn on unknown fields May 3, 2017

@bestform

This comment has been minimized.

Copy link

bestform commented May 4, 2017

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.

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented May 4, 2017

Thanks for feedback!

What would be part of [project] and why is it likely to be added?

The most immediate, functional need would be if we want to have Gopkg.toml indicate the root of the project. The reasons why that might be a good idea are pretty involved, so let's not delve into that, and just leave it at that there's a nonzero chance of wanting it.

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.

we lose the option to chose an alternative name for [project] later.

I'm not too worried about this one - I think project is pretty much settled terminology at this point, and Russ has indicated he's 👌 with it.

So it boils down to the probability of a project field.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment