4 ms·

I find it a bit strange that NPM and PyPI decided to have a single global namespace for packages. When there aren't very many packages it is more convenient, b

I find it a bit strange that NPM and PyPI decided to have a single global namespace for packages. When there aren't very many packages it is more convenient, but you very quickly run into issues of ownership of the names. This happened before during the glory days of SourceForge where project names were global, and there was all the resulting control and misdirection issues. Thankfully Github made it a two level namespace OWNER/PROJECT which vastly reduced the problems. IMHO the repositories will need to do something similar.

miohtama 4y ago
NPM has namespaces
- rogerbinns 4y ago
  Namespaces seem to be in the minority. For example searching for sqlite shows 124 pages where the vast majority of packages have no namespace. https://www.npmjs.com/search?q=sqlite https://www.npmjs.com/search?q=sqlite
- mort96 4y ago
  It has namespaces, but for the most part, packages are in the global namespace, most people publish packages there and most programmers use packages there. Namespaces aren't unused or useless in the NPM, but the fact that most packages people use aren't in namespaces means they don't do much for security.
  - miohtama 4y ago
    I agree with you. My point was about that in this case the problem is the users, or education, not the available features.
woodruffw 4y ago
I can understand not liking it, but I don't understand why you find it strange: global namespaces are the norm in language package distribution. RubyGems, NPM, PyPI, and Crates all use flat namespaces (either by default or as their only supported mode). Namespace partitioning has advantages, but it also doesn't solve squatting problems on its own: anybody (or any process) that's fooled by `requests` vs `pyrequests` is also going to be fooled by `some-owner/requests` vs. `requests-org/requests` (the latter being the fake one).
- phone8675309 4y ago
  Perl got this right 20 years ago.
  - nextaccountic 4y ago
    how does perl work in this regard?
  - woodruffw 4y ago
    I actually agree, but that's not namespacing in the way that the GP meant: Perl has curated topical namespaces that multiple unrelated users share, rather than identity or organization-owned namespaces.
  - duskwuff 4y ago
    I'm not convinced it did. In some ways it's worse -- Perl allows distributions to install modules inside another distribution's namespace.
- rogerbinns 4y ago
  I agree that namespacing doesn't solve all the problems, but I do think it significantly reduces the attack surface. It is sort of like a checksum for a package, combining the publisher name with the package name instead of having just bare package names.
  - woodruffw 4y ago
    Agreed! The problem is that the publisher's name isn't always clear: a lot of open source maintainers (myself included) publish major packages under their own name; a less familiar user could easily be confused into choosing the "official looking" name instead. I think the most "complete" solution here needs to involve code signing.
- cgh 4y ago
  One of the largest and oldest package repositories, Maven, got it right two decades ago. No one ever seems to mention it though.
dgb23 4y ago
Rust/cargo has the same issue. Somewhat surprising, since there are quite a bunch of languages, old and new ones, that do this right.
deleted 4y ago
[deleted]

miohtama 4y ago

NPM has namespaces

rogerbinns 4y ago
Namespaces seem to be in the minority. For example searching for sqlite shows 124 pages where the vast majority of packages have no namespace. https://www.npmjs.com/search?q=sqlite https://www.npmjs.com/search?q=sqlite
mort96 4y ago
It has namespaces, but for the most part, packages are in the global namespace, most people publish packages there and most programmers use packages there. Namespaces aren't unused or useless in the NPM, but the fact that most packages people use aren't in namespaces means they don't do much for security.
- miohtama 4y ago
  I agree with you. My point was about that in this case the problem is the users, or education, not the available features.

woodruffw 4y ago

I can understand not liking it, but I don't understand why you find it strange: global namespaces are the norm in language package distribution. RubyGems, NPM, PyPI, and Crates all use flat namespaces (either by default or as their only supported mode). Namespace partitioning has advantages, but it also doesn't solve squatting problems on its own: anybody (or any process) that's fooled by `requests` vs `pyrequests` is also going to be fooled by `some-owner/requests` vs. `requests-org/requests` (the latter being the fake one).

phone8675309 4y ago
Perl got this right 20 years ago.
- nextaccountic 4y ago
  how does perl work in this regard?
- woodruffw 4y ago
  I actually agree, but that's not namespacing in the way that the GP meant: Perl has curated topical namespaces that multiple unrelated users share, rather than identity or organization-owned namespaces.
- duskwuff 4y ago
  I'm not convinced it did. In some ways it's worse -- Perl allows distributions to install modules inside another distribution's namespace.
rogerbinns 4y ago
I agree that namespacing doesn't solve all the problems, but I do think it significantly reduces the attack surface. It is sort of like a checksum for a package, combining the publisher name with the package name instead of having just bare package names.
- woodruffw 4y ago
  Agreed! The problem is that the publisher's name isn't always clear: a lot of open source maintainers (myself included) publish major packages under their own name; a less familiar user could easily be confused into choosing the "official looking" name instead. I think the most "complete" solution here needs to involve code signing.
cgh 4y ago
One of the largest and oldest package repositories, Maven, got it right two decades ago. No one ever seems to mention it though.

dgb23 4y ago

Rust/cargo has the same issue. Somewhat surprising, since there are quite a bunch of languages, old and new ones, that do this right.

deleted 4y ago

[deleted]