Consider using package-url
pombredanne opened this issue · comments
As a new feature, it would be great to consider using package-url https://github.com/package-url to identify packages
This would allow referencing packages beyond npms.
My 2c: the idea behind package-url is great but the execution isn't. Imo there's a number of aspects of the spec. that are going in the wrong direction.
In the context of entropic, I think the package-url spec is particularly poorly suited.
This essentially comes down to their your approach to namespacing. Namespaces are—in a similar way to the original npm registry—terse, and they're also assigned on a per-authority/per-host basis, rather than per-language/per-ecosystem/etc.
This is fundamentally non-ideal for two reasons:
- terse namespaces (as has been seen with npm) lead to problems with scarcity. Name-squatting, name-hijacking, and general lack of clarity on package sourcing.
- a per-authority/per-host paradigm is somewhat incompatible with the idea of federation, and not particularly interop-friendly in general.
For an example of the latter, take even just the simple case of yarn -vs- npm. The JS-oriented namespace is npm, which points to https://registry.npm.org. This puts you at an immediate disadvantage if you wish to use https://registry.yarnpkg.com. One could create a yarn namespace but this seems superfluous for two interoperable & compatible package managers: are we expecting npm i and yarn i to someday migrate to generate different URIs to eachother in package.json? How messy would that get. This problem becomes more acute when you have tens/hundreds of repositories.
I had considered commenting this as an issue on the package-url repo (perhaps I should), but my reservations to the spec. are quite fundamental. So I'm not sure it's worthwhile to post such a critical ticket (let me know if you think I should). Really, while I can't fault the guys behind package-url you for trying to do something worthwhile in theory, I kind of secretly hope it doesn't catch on as it seems to be an aggregate of very centralised-/authority-oriented ideas. If it did become a standard, I fear it would restrict us from moving to more distributed/federated models.
@edwardgalligan thanks for the comments. I think you are mistaking package-url and namespaces to be prescriptive about anything, and in particular being prescriptive about a certain way to identify a package. A package-url is completely agnostic there, it is just trying to capture things as they are. The namespace segment of the name is both optional and needed as this is a concept that exists in a few "ecosystems", for instance npms and maven. I have no opinion whether this is a good or a bad thing. package-url are just capturing the fact they exist and offers a simple ecosystem-neutral syntax to capture such a namespace when it exists.
The JS-oriented namespace is npm, which points to https://registry.npm.org. This puts you at an immediate disadvantage if you wish to use https://registry.yarnpkg.com.
Side note: AFAIK you cannot upload anything to https://registry.yarnpkg.com and this is only a mirror of https://registry.npm.org to the best of my knowledge but I may be wrong, so yarnpkg.com is not something different from https://registry.yarnpkg.com ... just an alternative URL IMHO
FWIW If you want to point specifically to a package repository that is not the default, you could specify also it in a qualifier in a package-url... but in many cases that would be something handled outside of the URL itself.
It just happens that there is typically a default ecosystem-wide centralized registry that exists for a given package type. package-url's do not have an opinion there. This is what it is. Maven central, the npmjs registry, the PyPI index, Rubygems.irg all are the default centralized primary place serving heir ecosystems. You can use something else and you can even state this in a package-url .
In a package-url npm is NOT a namespace, this is a package type. Like maven or pypi. It encapsulate many things such as the manifest format and schema, the protocol to exchange with a package repo/index/registry and so on.
Instead, a package-url namespace would be this for a node package https://github.com/angular/angular/blob/c88305d2ebd5c8be3065dc356f7edbe4069d4ef3/packages/compiler/package.json#L2 e.g. @angular in an npm @angular/compiler
I had considered commenting this as an issue on the package-url repo (perhaps I should), but my reservations to the spec. are quite fundamental. So I'm not sure it's worthwhile to post such a critical ticket (let me know if you think I should).
Please do! ... here I think that entropic packages would need to be their own new package type in a package URL: this effectively captures the fact that there is a new and unique way to address a package (with a structured namespace ) , a new Package.toml manifest format and structure and a new API for a new registry: from a package-url point of view these are not npm types anymore. And this entropic package type would not have a default, centralized repository URL which is quite fine.
package-url are just capturing the fact they exist and offers a simple ecosystem-neutral syntax to capture such a namespace when it exists.
It just happens that there is typically a default ecosystem-wide centralized registry that exists for a given package type. package-url's do not have an opinion there. This is what it is.
I think you've outlined my point quite well here. The package-url spec. is descriptive, rather than perscriptive: i.e. it only describes and maintains the status quo.
This is a common trend in moderns specs nowadays: to standardise on what is popular, rather than to define a way forward. However this doesn't work for a federated or decentralised system, as they are—by definition—different from the status quo.
In a package-url npm is NOT a namespace
Just to clarify, my use of the word "namespace" was to mean the common generic word. I see you've used the word "namespace" to mean "package namespace within 1 ecosystem", which is fine. I meant the more general definition in my post above (i.e. a taxonomic string in general).
this entropic package type would not have a default, centralized repository URL which is quite fine.
This is good, and as I understand it this is also the case for Debian, golang and RPM in your listed examples. I just find the fact that these coexist with "authoritative", centralised "package types" to be contrary to the intent of entropic. It would be a much more flexible spec. if all "package types" also worked on the Debian/golang/RPM model.