I am not sure if this is a good idea

[metakeule]

If I get it correctly the main idea is,

Ideally, there would be one format for documenting the information that numerous tools 
(e.g. package managers) could all use and share.

Let me question this idea. I think your way to define use cases is a good way to try to identify what problems should be solved by a package manager. The way the package manager is organized will determine which information it needs in form of metadata. So by trying to define what metadata looks like you are basically defining what the package manager that use the data are able to do.

Then the question is: Why the need for different package managers at all if they are basically doing the same thing?

It would only make sense to have different package managers in order to explore different ways how to manage the packages. But if they would do so, they would need different metadata.

I'll give you some examples based on my gogistry proposal.

There I use a different kind semantic versioning for good reasons, since the gockage versioning variant make far more concrete promisses about compatibility: Incompatible with your spec.

Also the dependencies are described in a different way: an array of major numbers instead of different kinds of strings and comparions in betweens and whatever.

Also the property of a repository url and tags etc makes some hard assumptions that would not fit my use case: Gogistry is completely independant from any source control system and repository from tags and branches. So it does not make any sense there.

Also for Gogistry it makes more sense to have the dependencies and the meta data in different files.

What I am trying to tell is not that the spec should embrace the Gogistry way, but that any fruitful effort to develop a different package manager for Go only makes sense if it has a radically different approach. Then we could learn from it, if it works. But then this different efforts would require radically different metadata.

If all package managers work the same we should decide on one and improve it.

[mattfarina]

You ask some good questions in there...

Why the need for different package managers at all if they are basically doing the same thing?

I can see a reason for numerous package managers. You may have one that's an IDE add on. Another one for the CLI. Yet another CLI one that works with a special build too (e.g, gb and gb-vendor). The numerous CLI based ones could go away and we could standardize one one (like the other languages have).

for Gogistry it makes more sense to have the dependencies and the meta data in different files.

Why does it make sense to have the metadata in different files. You said that is does but not why. I'm curious for the reasoning.

I've looked at the Gogistry methodology and already asked some questions. As someone whose used package management tools for other languages I find it difficult on many levels. It introduces complexities without solving my problems. But, see that issue queue for my reaction to it.

[metakeule]

I can see a reason for numerous package managers. You may have one that's an IDE add on.

Well I think the IDE should shell out to a CLI. Other communities like Ruby or nodejs were able to standardize on a single CLI tool.

Why does it make sense to have the metadata in different files. You said that is does but not why. I'm curious for the reasoning.

Because normal go packages should also be able to specify their dependencies on Gockages while not being Gockages themself (and therefor not needing any meta data). The CLI tool then handles go packages and Gockages for dependency resolution but only Gockages for uploading et al. to the Gogistry.

[mattfarina]

A couple things about the examples you used...

1. I took a few minutes to see if there was a tool other than npm that worked with package.json data directly. It took just a few minutes to find a popular project and the line of code parsing the JSON. These tools do exist.
2. Ruby has not standardized on a single tool in practice. That's why there's Ruby Gems and Bundler. One does complement the other but they are different tools.

On the surface it may may seem like these communities are using a single tool. In practice it's more complicated and the well defined/documented specs have allowed some pretty cool things to happen.

Dropping down to a CLI is a design decision that doesn't always work. For example, what if someone wanted to audit or visualize the licenses used by npm packages? The npm CLI provides no tooling to do that. If a tool, like visual studio, wanted to display something it could do things a CLI designer wouldn't think of. Nothing in this example space is handled by the npm CLI but a well defined spec allows other tools to be in this space.

Note, the license issue is one of our use cases and there are tools for this in other languages (e.g., npm-license).

Grockages, your proposed alternative is more than a packaging standard. It's a new way of doing packages that doesn't enable those building in the current system. It specifies that all packages be licensed as GPLv2 and in a central location. The code characteristics is to be quite high (100% test coverage).

This sounds more like the manifesto around a closed system for packages.

While I fully support your right to go after Grockages and the Gogistry, I do not believe this is a palatable solution for the current Go community or those likely to adopt it. It's certainly not a good solution for many of the people I collaborate with and it can't replace what's here.

By all means go after your solution. Let the market work out what it will choose to use over the long haul. But, what you have doesn't mean this isn't a good idea.

I will be going through the issues this week and closing the ones that are a difference of opinion, like this one, that are not resulting in actions (such as new use cases, alterations to use cases, etc).

[mattfarina]

Since this issue is more about Gogistry/Gochages compared to this spec (or one of any kind) and that's a philosophical debate rather than a technical one I'm going to close the issue. I look forward to the market (users) deciding.