(Replying to PARENT post)

Another reminder of how annoying it is for a package system to have unqualified package names.

Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`.

This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better.

You see all sorts of problems because of this, like people "giving packages away" when they quit. Or buying package names. Or coming up with annoying name hacks because the obvious, best name is simply taken. Or people thinking/guessing that `npm install mysql` is the correct/best/canonical package because it's the simplest name, and anyone who publishes a better library has to name it mysql2 or better-mysql, etc. These just shouldn't even be things.

👤hombre_fatal🕑6y🔼0🗨️0

(Replying to PARENT post)

> It's just infinitely, obviously better.

Whenever a large number of skilled people do something for which an alternative is "infinitely, obviously better", there's a good chance that there is more going on than you know.

RubyGems used to be namespaced this way and moved away from it. They didn't do so lightly.

The problem is that ownership, and even names of owners change all the time. In the very very large majority of cases, this change of ownership is an implementation detail that doesn't need to impact package consumers. If you enshrine the owner's name in the package, it means any change of ownership is effectively a breaking change to the package. When you have very large transitive dependency graphs, the result is constant, pointless churn.

👤munificent🕑6y🔼0🗨️0

(Replying to PARENT post)

How would that have helped things in this case? If we go with the hypothesis of an angry maintainer getting revenge, would they not be just as angry at their project being forked by the community, and just as able to sabotage it via other libraries still in their namespace? (And perhaps more willing, since their original name is still around.) If we go with the hypothesis of a compromised account, people will still be installing the package from the original maintainer's namespace, so they'll still get the malicious code.

And in all likelihood, because the story here is that the maintainer intentionally (though begrudgingly) transferred ownership, they would have intentionally (though begrudgingly) given other people access to the package in their namespace, simply because people value the namespaced name. (If they didn't, and everyone was immediately happy to install anyone/purescript, then namespacing doesn't solve any problems and also creates some!) And the situation would have played out as given.

👤geofft🕑6y🔼0🗨️0

(Replying to PARENT post)

Imo your solution is just a band aid. The real solution is having a distribution of packages which are maintained and suppervised by a group of people. Like the linux distribution maintainers or the group that develops the language.

Community contribuited packages should be declared "install at own risk" like in archlinux aur.

All this is already solved. But people want to reinvent the wheel and ride the user generated content train.

👤trabant00🕑6y🔼0🗨️0

(Replying to PARENT post)

Java got that part right in the 1990s, when it was the cool Web-savvy language. At the time, I especially liked how they piggybacked onto the existing DNS domain name control, avoiding having to create a new centralized registry to keep names unique. (Of course, more could be done beyond that, today.)
👤neilv🕑6y🔼0🗨️0

(Replying to PARENT post)

This is not a package namespacing issue. This is not a technical issue. It is mechanically no more difficult to change from "@shinn/purescript" to "@whatever/purescript" than it is to change from "purescript" to "purescript-whatever", except that in the common cases (where no disputed community moves have occurred without a corresponding name change) everyone has to include an author. The author can still "give away" or sell package names; a lot the value is not in holding the name, but having the existing installed base and mindshare.

These are the social issues associated with a hostile fork.

👤naniwaduni🕑6y🔼0🗨️0

(Replying to PARENT post)

I don't actually feel like this solves anything, but instead just adds one more avenue for name hijacking. Now instead of trying to register an angular package first, I'll try to register a google namespace, or similar. If google is taken, I'll make an official_google, or g00gle etc.
👤timothycrosley🕑6y🔼0🗨️0

(Replying to PARENT post)

Even PHP gets this right. It's not hard. It makes me wonder why npm hasn't already moved to namespaced package names.
👤McGlockenshire🕑6y🔼0🗨️0

(Replying to PARENT post)

> It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`.

And how is a user supposed to make the difference between @legit_dev/package_name and something like @nlegit_dev/package ?

Namespacing makes name-squatting way easier, not harder.

👤littlestymaar🕑6y🔼0🗨️0

(Replying to PARENT post)

There's nothing preventing whatever_purescript. Even if you have namespacing, anyone who owns a spot in it can sell or rent their spot to a malicious actor.
👤lonelappde🕑6y🔼0🗨️0

(Replying to PARENT post)

Fortunately it seems to be something that Entropic gets right:

https://github.com/entropic-dev/entropic

If it ends up supporting PGP signatures for packages (ideally created by developers using air-gapped machines) then so much the better:

https://github.com/entropic-dev/entropic/issues/86#issuecomm...

👤dane-pgp🕑6y🔼0🗨️0

(Replying to PARENT post)

Java got this right with reverse domain names over a decade ago. To use a namespace you have to own the URL. Simple and effective abuse resistant package naming.
👤nullwasamistake🕑6y🔼0🗨️0