5 ms·

Has anybody considered not having a single global repository of JS packages? (Also, as usual, has anybody considered just not doing this whole JS thing?)

kuzirashi 9y ago
Can you elaborate on this? What's the alternative to single global repository? By single global repository you mean NPM?
- paulddraper 9y ago
  The alternative is many. E.g. apt.
  - krapp 9y ago
    Even PHP manages to get this right - Composer uses the Packagist repository as a default but just about any git or svn repo with a URL will do.
    - jaredsohn 9y ago
      npm supports git urls, too (or the even shorter user/project#tag if it is from github)
      - manquer 9y ago
        Composer also supports namespacing
  - shawnz 9y ago
    Does apt allow you to have multiple packages with the same name from different repositories? I don't see how it solves this issue otherwise.
    - paulddraper 9y ago
      No, it does not. But I don't use the vast majority of apt repos. I use a handful of well-curated ones with high-quality software, plus a handful for one-off packages. In contrast, there's basically no limit to how much debris you can upload to npm.
  - kuzirashi 9y ago
    There's a lot of problems with APT. :)
- dragonwriter 9y ago
  Separate uncoordinated repositories (which risks namespace collisions), or separate repositories with a rule effectively providing a system for assuring universally unique names, e.g., by prefixing project names with the identification of the repository responsible for the local uniqueness of the name.
- DonbunEf7 9y ago
  An example alternative is a ports tree. You have a repository which can build packages from descriptions. This repository itself is a formal parameter, so it can be replaced easily. It's also a basic filesystem structure that doesn't depend on external services directly in order to be queried. At this point in history, we are starting to become much more capable of federating basic read-only filesystems, so the availability of a simple ports tree (and any referent tarballs) are no longer depending as much on central authority servers. In addition to the BSDs, this is how the Nix ecosystem manages its package repositories. There is (of course [0]) a singularly large repository, nixpkgs, but there are also forks which can vary greatly in appearance, from nixpkgs + custom packages, all the way to systems like Triton, which replace a lot of the fundamental repository structure. Nonetheless, they are largely interchangeable at the top level. NPM would have to be distributed as a git repository, at the least, for this to be feasible. [0] Why is there always a single large structure at the center of repositories of data? It's because data likes to aggregate as a side-effect of what some people call "network effects" or "economies of scale" or "Boyle's law", although I'm not sure that any of them cover it succinctly. The best introduction to this that I know of is the two-balloon experiment: https://en.wikipedia.org/wiki/Two-balloon_experiment https://en.wikipedia.org/wiki/Two-balloon_experiment
niftich 9y ago
Perhaps you mean "has anybody considered having formal, hierarchical namespaces", an orthogonal concern to having or not having a single global repository (although the two can be coupled together by the community if they so choose). To which the answer is yes [1][2][3][4]. [1] https://github.com/npm/npm/issues/798 https://github.com/npm/npm/issues/798 [2] https://github.com/npm/npm/issues/5239 https://github.com/npm/npm/issues/5239 [3] http://blog.npmjs.org/post/116936804365/solving-npms-hard-problem-naming-packages http://blog.npmjs.org/post/116936804365/solving-npms-hard-pr... [4] https://docs.npmjs.com/getting-started/scoped-packages https://docs.npmjs.com/getting-started/scoped-packages

kuzirashi 9y ago

Can you elaborate on this? What's the alternative to single global repository? By single global repository you mean NPM?

paulddraper 9y ago
The alternative is many. E.g. apt.
- krapp 9y ago
  Even PHP manages to get this right - Composer uses the Packagist repository as a default but just about any git or svn repo with a URL will do.
  - jaredsohn 9y ago
    npm supports git urls, too (or the even shorter user/project#tag if it is from github)
    - manquer 9y ago
      Composer also supports namespacing
- shawnz 9y ago
  Does apt allow you to have multiple packages with the same name from different repositories? I don't see how it solves this issue otherwise.
  - paulddraper 9y ago
    No, it does not. But I don't use the vast majority of apt repos. I use a handful of well-curated ones with high-quality software, plus a handful for one-off packages. In contrast, there's basically no limit to how much debris you can upload to npm.
- kuzirashi 9y ago
  There's a lot of problems with APT. :)
dragonwriter 9y ago
Separate uncoordinated repositories (which risks namespace collisions), or separate repositories with a rule effectively providing a system for assuring universally unique names, e.g., by prefixing project names with the identification of the repository responsible for the local uniqueness of the name.
DonbunEf7 9y ago
An example alternative is a ports tree. You have a repository which can build packages from descriptions. This repository itself is a formal parameter, so it can be replaced easily. It's also a basic filesystem structure that doesn't depend on external services directly in order to be queried. At this point in history, we are starting to become much more capable of federating basic read-only filesystems, so the availability of a simple ports tree (and any referent tarballs) are no longer depending as much on central authority servers. In addition to the BSDs, this is how the Nix ecosystem manages its package repositories. There is (of course [0]) a singularly large repository, nixpkgs, but there are also forks which can vary greatly in appearance, from nixpkgs + custom packages, all the way to systems like Triton, which replace a lot of the fundamental repository structure. Nonetheless, they are largely interchangeable at the top level. NPM would have to be distributed as a git repository, at the least, for this to be feasible. [0] Why is there always a single large structure at the center of repositories of data? It's because data likes to aggregate as a side-effect of what some people call "network effects" or "economies of scale" or "Boyle's law", although I'm not sure that any of them cover it succinctly. The best introduction to this that I know of is the two-balloon experiment: https://en.wikipedia.org/wiki/Two-balloon_experiment https://en.wikipedia.org/wiki/Two-balloon_experiment

niftich 9y ago

Perhaps you mean "has anybody considered having formal, hierarchical namespaces", an orthogonal concern to having or not having a single global repository (although the two can be coupled together by the community if they so choose). To which the answer is yes [1][2][3][4]. [1] https://github.com/npm/npm/issues/798 https://github.com/npm/npm/issues/798 [2] https://github.com/npm/npm/issues/5239 https://github.com/npm/npm/issues/5239 [3] http://blog.npmjs.org/post/116936804365/solving-npms-hard-problem-naming-packages http://blog.npmjs.org/post/116936804365/solving-npms-hard-pr... [4] https://docs.npmjs.com/getting-started/scoped-packages https://docs.npmjs.com/getting-started/scoped-packages