5 ms·

The module name is a good example of why package systems should have qualified names by default. `npm install JoshuaWise/sqlite3` Elm got this right. You shoul

The module name is a good example of why package systems should have qualified names by default. `npm install JoshuaWise/sqlite3` Elm got this right. You shouldn't have to be clever in thinking of a package name just because the obvious one was taken and you have a different flavor to offer. Rust didn't and it's another ecosystem where people feel the need to squat on names or suffix a '2' when they think they've written a better library, just like NPM.

vog 9y ago
On the other hand, for LaTeX (see CTAN) this works astonishingly well. Those also have a much stronger emphasis on backwards compatibility of existing packages. I suspect this is not just a coincidence.
hnarn 9y ago
I like this idea. Maybe you could even have a more fun variant where you add a random goofy adjective ("big" is unsuitable because it could mean something, but "sparkly" hardly has bearing on a software package), or something else that is randomly assigned rather than propagating someone's user name. Sometimes it's a one man package but for a package with 300 contributors it doesn't make sense why someone's name should be slapped onto it forever.
- reificator 9y ago
  If it's a package with 300 contributors you would use an organization's name, not a person's name.
  - hnarn 9y ago
    Ok, so what happens when the same package evolves from one person to a team of 300 people?
    - reificator 9y ago
      Then you migrate. If the platform provides tools to do that, you use them. Otherwise you make a new namespace, upload the project to the new one, and edit the old one with a link to the new one and a deprecation warning. Then if you have a trusted announcement platform like a blog or Twitter, announce it there. If it's feasible to do so, you also push updates to both namespaces for a little while during the transition.
      - always_good 9y ago
        And I think the package manager can do so much more here than current ones from a UX level. For example, instead of having to push updates to both packages, you push updates to the new one and, because you've annotated the old one with the move, users have a somewhat seamless experience when they run their update: they'll get a little heads up about the move, explain that oldpackage eol'd at 5.4 and newpackage picked up at 6.0, and would you like me auto-update your manifest? And/or the package manager supports a rename flow that does this for you.
        reificator 9y ago
        Yeah, like I said, if the platform provides that kind of tooling, take advantage of it.
- always_good 9y ago
  I think a package manager should have first-class support for those sorts of governance changes because these structures change. For example, packages direct to their latest state. Trying to upgrade a package with an org change will explain this during your next update. Github has some good examples of this when repos change hands.
kryptiskt 9y ago
And then you can't transfer a package to a new organization without stranding users. Java showed how misguided using the domain name in the package name was, organizations have far less permanence than software.
- scrollaway 9y ago
  I think there's middle ground. Github manages somehow (by creating redirects). I'm having the exact problem you're describing in a macOS app, where an app that was previously name.janedoe.app is now org.company.app. What a mess that caused.
- oblio 9y ago
  Meh, nobody cares about package names, anyway. I've seen plenty of companies who had com.acquisition1, com.acquisition2, etc., all over the place. The Java space, Maven, more precisely, did come up with the first namespaces package repository. For some reason other package managers don't do it, for simplicity I guess, and it always come back to bite them in the butt. For reference, Maven 1 didn't have groupIds, Maven 2 added them. They did it for a reason and that was back in 2005!
- always_good 9y ago
  This can be managed in many ways, like identity immutability, package redirection, and solved from a UI standpoint like "a/foo was moved to b/foo" on your user's next package update because the package manager has first-class support for it. Did you think nothing can be improved upon Java?
mirkonasato 9y ago
npm does support "scoped packages"[1], since 2015. More projects are starting to use them, e.g. Angular publishes packages like @angular/core, @angular/forms, etc. [1] https://docs.npmjs.com/misc/scope https://docs.npmjs.com/misc/scope
- sebazzz 9y ago
  Yes, but they don't enforce it for new packages.
- always_good 9y ago
  Yeah, this is why I snuck "by default" in there. It's not that great unless it's required. For example, the bare "sqlite3" package name will always sound official/canonical next to "@JoshuaWise/sqlite3" and people will forever accidentally install it even though they want a scope. Just like how users type in domain.com when they really wanted domain.org.
fnord123 9y ago
You can still do JoshuaWise-sqlite3.
- always_good 9y ago
  You can do scoped packages like @JoshuaWise/sqlite3 but it's like getting a crappy tld because the .com was taken -- the bare "sqlite3" package seems like the better/canonical/official package, people are going to try to install it anyways, etc. It doesn't really work until FQN is required by all.

vog 9y ago

On the other hand, for LaTeX (see CTAN) this works astonishingly well. Those also have a much stronger emphasis on backwards compatibility of existing packages. I suspect this is not just a coincidence.

hnarn 9y ago

I like this idea. Maybe you could even have a more fun variant where you add a random goofy adjective ("big" is unsuitable because it could mean something, but "sparkly" hardly has bearing on a software package), or something else that is randomly assigned rather than propagating someone's user name. Sometimes it's a one man package but for a package with 300 contributors it doesn't make sense why someone's name should be slapped onto it forever.

reificator 9y ago
If it's a package with 300 contributors you would use an organization's name, not a person's name.
- hnarn 9y ago
  Ok, so what happens when the same package evolves from one person to a team of 300 people?
  - reificator 9y ago
    Then you migrate. If the platform provides tools to do that, you use them. Otherwise you make a new namespace, upload the project to the new one, and edit the old one with a link to the new one and a deprecation warning. Then if you have a trusted announcement platform like a blog or Twitter, announce it there. If it's feasible to do so, you also push updates to both namespaces for a little while during the transition.
    - always_good 9y ago
      And I think the package manager can do so much more here than current ones from a UX level. For example, instead of having to push updates to both packages, you push updates to the new one and, because you've annotated the old one with the move, users have a somewhat seamless experience when they run their update: they'll get a little heads up about the move, explain that oldpackage eol'd at 5.4 and newpackage picked up at 6.0, and would you like me auto-update your manifest? And/or the package manager supports a rename flow that does this for you.
      - reificator 9y ago
        Yeah, like I said, if the platform provides that kind of tooling, take advantage of it.
always_good 9y ago
I think a package manager should have first-class support for those sorts of governance changes because these structures change. For example, packages direct to their latest state. Trying to upgrade a package with an org change will explain this during your next update. Github has some good examples of this when repos change hands.

kryptiskt 9y ago

And then you can't transfer a package to a new organization without stranding users. Java showed how misguided using the domain name in the package name was, organizations have far less permanence than software.

scrollaway 9y ago
I think there's middle ground. Github manages somehow (by creating redirects). I'm having the exact problem you're describing in a macOS app, where an app that was previously name.janedoe.app is now org.company.app. What a mess that caused.
oblio 9y ago
Meh, nobody cares about package names, anyway. I've seen plenty of companies who had com.acquisition1, com.acquisition2, etc., all over the place. The Java space, Maven, more precisely, did come up with the first namespaces package repository. For some reason other package managers don't do it, for simplicity I guess, and it always come back to bite them in the butt. For reference, Maven 1 didn't have groupIds, Maven 2 added them. They did it for a reason and that was back in 2005!
always_good 9y ago
This can be managed in many ways, like identity immutability, package redirection, and solved from a UI standpoint like "a/foo was moved to b/foo" on your user's next package update because the package manager has first-class support for it. Did you think nothing can be improved upon Java?

mirkonasato 9y ago

npm does support "scoped packages"[1], since 2015. More projects are starting to use them, e.g. Angular publishes packages like @angular/core, @angular/forms, etc. [1] https://docs.npmjs.com/misc/scope https://docs.npmjs.com/misc/scope

sebazzz 9y ago
Yes, but they don't enforce it for new packages.
always_good 9y ago
Yeah, this is why I snuck "by default" in there. It's not that great unless it's required. For example, the bare "sqlite3" package name will always sound official/canonical next to "@JoshuaWise/sqlite3" and people will forever accidentally install it even though they want a scope. Just like how users type in domain.com when they really wanted domain.org.

fnord123 9y ago

You can still do JoshuaWise-sqlite3.

always_good 9y ago
You can do scoped packages like @JoshuaWise/sqlite3 but it's like getting a crappy tld because the .com was taken -- the bare "sqlite3" package seems like the better/canonical/official package, people are going to try to install it anyways, etc. It doesn't really work until FQN is required by all.