7 ms·

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name

by gw 6y ago

You really should look to other ecosystems and see what lessons they've learned. In java, packages are normally "namespaced" by the author's reverse domain name, like `org.lwjgl/lwjgl`. Since clojure uses maven as well, the same applies, but clojure tools like leiningen decided to create a shortcut: if the group and artifact name are the same, like `iglu/iglu`, they can be collapsed into one name: `iglu` Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? Most now seem to agree it wasn't a good idea. When the "collapsed" name falls out of maintenance, the forks will all seem somehow less "official", even if they are much higher quality. Forks are inevitable; why would you want to discourage them? I finally decided to start using the reverse of my personal domain for my future libraries. The java folks were right all along.

dllthomas 6y ago
> Forks are inevitable; why would you want to discourage them? The conclusion that we don't want to discourage forks may be valid, but this doesn't seem to be good reasoning. Lots of things are inevitable that we want to discourage or delay.
setr 6y ago
>Forks are inevitable; why would you want to discourage them? The epitome of this mindset I think is "hostile fork" -- the entire notion is nonsensical. The whole point of being FOSS/OSS is the freedom to fork -- by all damn rights, you should fork as you please, and be pleased to fork! The actual problem is not forking.. its community fragmentation, and more importantly loss of a "source of truth". Of course, maintaining that source of truth is otherwise known as centralization, with all the problems that brings, but there's nothing inherently wrong with forking.. that's just the natural specialization and evolutionary processes at work. The solution is to make it easier to find those top-tier libraries, and this is orthogonal to forking; mainly handled by blog posts and "official" library listings/recommendations, and things like This Week in Rust.... namespacing or not doesn't really get you anything there.
- PuercoPop 6y ago
  > "hostile fork" -- the entire notion is nonsensical. It is not. It is based in experience. See the xMule/aMule fork. A hostile fork is when the fork project starts bad-mouthing the original project and its maintainers. The notion that forking is by itself hostile is non-sense.
  - nitrogen 6y ago
    If I'm remembering right, something similar kind of happened with uBlock and uBlock Origin, but it was the original maintainer who came back and forked after the new maintainer became hostile, or something like that.
- hyperman1 6y ago
  This was discussed in detail in Homesteading the Noosphere of Eric S Raymond. I think it's in there somewhere that he compares the right to fork with the right to bear arms: Good to have, but the situation must have gotten really shitty if a fork is a good solution. https://firstmonday.org/ojs/index.php/fm/article/download/1474/1389/14789#d3 https://firstmonday.org/ojs/index.php/fm/article/download/14...
steveklabnik 6y ago
We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Both the good and the bad. And also by the experience of going through GitHub hosting a RubyGems server and all the fallout that happened there.
- simon_o 6y ago
  I think what the GP wanted to say was along the lines of "look at _better_ approaches", not just "look at approaches".
  - steveklabnik 6y ago
    Maybe. Regardless of what my parent meant, a lot of people in these discussions imply that we never looked at prior art because we did not make the choices around the tradeoff that they wanted us to make. And we did look at many, many approaches. We just decided to not go in those directions.
    - simon_o 6y ago
      If your prior art consists of "informed by several of us having experience with CPAN, RubyGems, and npm" it's no surprise that cargo suffers from the issues it currently suffers from.
      - steveklabnik 6y ago
        It is not a comprehensive list of things considered, it is a list of successful ecosystems that we decided to pick something closer to, than others that we decided not to. And even grouping those together in terms of downsides is not really doing justice to the individual problems that each of those systems deal with.
    - gw 6y ago
      I wasn't even addressing the crates.io team, i was addressing the author of the post.
didibus 6y ago
Agree, Go went a similar route as Java and I think that's good as well. The new tools.deps in Clojure actually is moving to disallow collapsed names for similar reason and will force iglu/iglu. Here's a rationale from them: > The groupId exists to disambiguate library names so our ecosystem is not just a race to grab unqualified names. The naming convention in Maven for groupId is to follow Java’s package naming rules and start with a reversed domain name or a trademark, something you control. Maven itself does not enforce this but the Maven Central repository does all new projects. > In cases where you have a lib with no domain name or trademark, you can use a third party source of identity (like github) in combination with an id you control on that site, so your lib id would be github-yourname/yourlib. Using a dashed name is preferred over a dotted name as that could imply a library owned by github.
- kibwen 6y ago
  Can I get a link to the quoted document? The quote raises more questions than it answers. Who determines that someone applying for a qualified name is the owner of that trademark (presumably this is a full-time employee; who pays their salary?), and what is the process? Trademarks are not a universal namespace--even within a single legal jurisdiction you can have the same name legally owned by different people due to different contexts--so who decides who wins?
  - gw 6y ago
    The quote was a guideline, not a requirement. Cognitect (who makes the clojure CLI tool) doesn't even control clojars, the main clojure maven repo, so they wouldn't be able to enforce that even if they wanted to.
  - didibus 6y ago
    The quote is from: https://insideclojure.org/2020/07/28/clj-exec/ https://insideclojure.org/2020/07/28/clj-exec/ under section "Deprecated unqualified lib names". That said, ya this is best intentions unfortunately. I'm guessing if you own a real trademark, you could actually sue people using your trademark as their group-id. Otherwise in general they recommend using a registered web domain name. Someone else could take over your domain name as theirs, but I think the registry owner, like maven-central, if you contacted them and could show you own that domain, they might be able to take actions against the impersonator. Same for a github user. Actually, thinking about this, I feel it be great if the repository owner like maven-central required a form of proof of ownership of the domain or the github id. That could add a lot of trust to the whole process.
kibwen 6y ago
> Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? This appears to be using evidence to prove the opposite conclusion; if everyone voluntarily chose to use shorter names, then it means that everyone cares about having shorter names. If there is a more substantial argument for why people have decided that the collapsing was mistake, I'd like to read it.
- gw 6y ago
  I didn't choose the shorter names because i "care[d] about having shorter names", i did so defensively, because i figured if i chose `net.sekao/iglu`, someone else would choose `iglu/iglu` which would imply that theirs was the original or official version. Another point i didn't mention is that maven was designed from the start to be decentralized; many companies run their own private maven repos, but also pull artifacts from maven central. Having group names reduces the chances of collisions between their private servers and a public maven server.
  - kibwen 6y ago
    That's a better rationale, although I don't think that really solves your stated problem; as an uninformed user I am still more likely to think that iglu/iglu is the more authoritative source there. Given this, any project that wants to authoritatively own its identifier should probably also register its own top-level namespace... which unfortunately brings us back around to where we started.
    - gw 6y ago
      It would at least be far less of an issue. I don't see anyone being confused that https://github.com/facebook/react https://github.com/facebook/react is the official repo, and not https://github.com/react/react https://github.com/react/react. It's the fact that a collapsed name is a shortcut that imbues it with this special stature. And i believe maven central doesn't even allow one-segment group names for new libraries, though clojars obviously does.
hinkley 6y ago
Java was my introduction to namespacing, so I only suspected but didn't know for a long time that Java overdid namespacing. Companies change names, they merge. Sometimes they go out of business but stick around as a foundation stewarding their old projects, and you might be going to example.org for years for documentation on a com.example module. And the namespaces weren't enforced (who is going to stop me from publishing a com.example.foo module?), so it expected much and delivered little. No namespaces is bad. Five level namespaces are better, but still bad for different reasons. Two might be good. Some might prefer three. But zero is right out.
- tasogare 6y ago
  I agree, the Java namespace system isn’t that good. In fact I hate it. First because it uses reverse DNS while common use of URL are in the opposite order. Second because the package sbu-namespace is enforced with the file system structure, which makes for crazy long names. On the other hand I really like how C# and dotnet in general handle the matter. Package namespace are separated from logical (in-code) namespace. Package namespace are usually two/three dotted term, making ownership clear while not bloating the names.
  - valenterry 6y ago
    > First because it uses reverse DNS while common use of URL are in the opposite order. Well, that's more a bad thing about the DNS though. "toplevel.domainname.subdomain/path" should really be how it should be structured. SUN improved this and made the hierarchy proper.
    - afiori 6y ago
      my understanding of DNS is that it actually uses ".tld.domain.subdomain" as a representation, it is just the URL format that mixes them up
- Symbiote 6y ago
  The Maven Central repository will not allow you to publish a Java package com.example.foo.
andylynch 6y ago
The team at Sun really got this right. I recall an interesting precursor in Solaris/ System V - the OS package guidelines recommended using your _stock ticker_ as part of the short name.

by gw 6y ago

dllthomas 6y ago

> Forks are inevitable; why would you want to discourage them? The conclusion that we don't want to discourage forks may be valid, but this doesn't seem to be good reasoning. Lots of things are inevitable that we want to discourage or delay.

setr 6y ago

>Forks are inevitable; why would you want to discourage them? The epitome of this mindset I think is "hostile fork" -- the entire notion is nonsensical. The whole point of being FOSS/OSS is the freedom to fork -- by all damn rights, you should fork as you please, and be pleased to fork! The actual problem is not forking.. its community fragmentation, and more importantly loss of a "source of truth". Of course, maintaining that source of truth is otherwise known as centralization, with all the problems that brings, but there's nothing inherently wrong with forking.. that's just the natural specialization and evolutionary processes at work. The solution is to make it easier to find those top-tier libraries, and this is orthogonal to forking; mainly handled by blog posts and "official" library listings/recommendations, and things like This Week in Rust.... namespacing or not doesn't really get you anything there.

PuercoPop 6y ago
> "hostile fork" -- the entire notion is nonsensical. It is not. It is based in experience. See the xMule/aMule fork. A hostile fork is when the fork project starts bad-mouthing the original project and its maintainers. The notion that forking is by itself hostile is non-sense.
- nitrogen 6y ago
  If I'm remembering right, something similar kind of happened with uBlock and uBlock Origin, but it was the original maintainer who came back and forked after the new maintainer became hostile, or something like that.
hyperman1 6y ago
This was discussed in detail in Homesteading the Noosphere of Eric S Raymond. I think it's in there somewhere that he compares the right to fork with the right to bear arms: Good to have, but the situation must have gotten really shitty if a fork is a good solution. https://firstmonday.org/ojs/index.php/fm/article/download/1474/1389/14789#d3 https://firstmonday.org/ojs/index.php/fm/article/download/14...

steveklabnik 6y ago

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Both the good and the bad. And also by the experience of going through GitHub hosting a RubyGems server and all the fallout that happened there.

simon_o 6y ago
I think what the GP wanted to say was along the lines of "look at _better_ approaches", not just "look at approaches".
- steveklabnik 6y ago
  Maybe. Regardless of what my parent meant, a lot of people in these discussions imply that we never looked at prior art because we did not make the choices around the tradeoff that they wanted us to make. And we did look at many, many approaches. We just decided to not go in those directions.
  - simon_o 6y ago
    If your prior art consists of "informed by several of us having experience with CPAN, RubyGems, and npm" it's no surprise that cargo suffers from the issues it currently suffers from.
    - steveklabnik 6y ago
      It is not a comprehensive list of things considered, it is a list of successful ecosystems that we decided to pick something closer to, than others that we decided not to. And even grouping those together in terms of downsides is not really doing justice to the individual problems that each of those systems deal with.
  - gw 6y ago
    I wasn't even addressing the crates.io team, i was addressing the author of the post.

didibus 6y ago

Agree, Go went a similar route as Java and I think that's good as well. The new tools.deps in Clojure actually is moving to disallow collapsed names for similar reason and will force iglu/iglu. Here's a rationale from them: > The groupId exists to disambiguate library names so our ecosystem is not just a race to grab unqualified names. The naming convention in Maven for groupId is to follow Java’s package naming rules and start with a reversed domain name or a trademark, something you control. Maven itself does not enforce this but the Maven Central repository does all new projects. > In cases where you have a lib with no domain name or trademark, you can use a third party source of identity (like github) in combination with an id you control on that site, so your lib id would be github-yourname/yourlib. Using a dashed name is preferred over a dotted name as that could imply a library owned by github.

kibwen 6y ago
Can I get a link to the quoted document? The quote raises more questions than it answers. Who determines that someone applying for a qualified name is the owner of that trademark (presumably this is a full-time employee; who pays their salary?), and what is the process? Trademarks are not a universal namespace--even within a single legal jurisdiction you can have the same name legally owned by different people due to different contexts--so who decides who wins?
- gw 6y ago
  The quote was a guideline, not a requirement. Cognitect (who makes the clojure CLI tool) doesn't even control clojars, the main clojure maven repo, so they wouldn't be able to enforce that even if they wanted to.
- didibus 6y ago
  The quote is from: https://insideclojure.org/2020/07/28/clj-exec/ https://insideclojure.org/2020/07/28/clj-exec/ under section "Deprecated unqualified lib names". That said, ya this is best intentions unfortunately. I'm guessing if you own a real trademark, you could actually sue people using your trademark as their group-id. Otherwise in general they recommend using a registered web domain name. Someone else could take over your domain name as theirs, but I think the registry owner, like maven-central, if you contacted them and could show you own that domain, they might be able to take actions against the impersonator. Same for a github user. Actually, thinking about this, I feel it be great if the repository owner like maven-central required a form of proof of ownership of the domain or the github id. That could add a lot of trust to the whole process.

kibwen 6y ago

> Well, that just encouraged everyone to choose collapsible names. In retrospect, this didn't buy us much. Who cares about saving a few characters of typing? This appears to be using evidence to prove the opposite conclusion; if everyone voluntarily chose to use shorter names, then it means that everyone cares about having shorter names. If there is a more substantial argument for why people have decided that the collapsing was mistake, I'd like to read it.

gw 6y ago
I didn't choose the shorter names because i "care[d] about having shorter names", i did so defensively, because i figured if i chose `net.sekao/iglu`, someone else would choose `iglu/iglu` which would imply that theirs was the original or official version. Another point i didn't mention is that maven was designed from the start to be decentralized; many companies run their own private maven repos, but also pull artifacts from maven central. Having group names reduces the chances of collisions between their private servers and a public maven server.
- kibwen 6y ago
  That's a better rationale, although I don't think that really solves your stated problem; as an uninformed user I am still more likely to think that iglu/iglu is the more authoritative source there. Given this, any project that wants to authoritatively own its identifier should probably also register its own top-level namespace... which unfortunately brings us back around to where we started.
  - gw 6y ago
    It would at least be far less of an issue. I don't see anyone being confused that https://github.com/facebook/react https://github.com/facebook/react is the official repo, and not https://github.com/react/react https://github.com/react/react. It's the fact that a collapsed name is a shortcut that imbues it with this special stature. And i believe maven central doesn't even allow one-segment group names for new libraries, though clojars obviously does.

hinkley 6y ago

Java was my introduction to namespacing, so I only suspected but didn't know for a long time that Java overdid namespacing. Companies change names, they merge. Sometimes they go out of business but stick around as a foundation stewarding their old projects, and you might be going to example.org for years for documentation on a com.example module. And the namespaces weren't enforced (who is going to stop me from publishing a com.example.foo module?), so it expected much and delivered little. No namespaces is bad. Five level namespaces are better, but still bad for different reasons. Two might be good. Some might prefer three. But zero is right out.

tasogare 6y ago
I agree, the Java namespace system isn’t that good. In fact I hate it. First because it uses reverse DNS while common use of URL are in the opposite order. Second because the package sbu-namespace is enforced with the file system structure, which makes for crazy long names. On the other hand I really like how C# and dotnet in general handle the matter. Package namespace are separated from logical (in-code) namespace. Package namespace are usually two/three dotted term, making ownership clear while not bloating the names.
- valenterry 6y ago
  > First because it uses reverse DNS while common use of URL are in the opposite order. Well, that's more a bad thing about the DNS though. "toplevel.domainname.subdomain/path" should really be how it should be structured. SUN improved this and made the hierarchy proper.
  - afiori 6y ago
    my understanding of DNS is that it actually uses ".tld.domain.subdomain" as a representation, it is just the URL format that mixes them up
Symbiote 6y ago
The Maven Central repository will not allow you to publish a Java package com.example.foo.

andylynch 6y ago

The team at Sun really got this right. I recall an interesting precursor in Solaris/ System V - the OS package guidelines recommended using your _stock ticker_ as part of the short name.