In python we do pip install myLib.
In linux we do apt-get install myTool.
And there are many such examples.
Why in Scala we need to include full “address” of the library io.whatever.myHub % myLib?
I really don’t understand it, and I guess there is probably a reason, but we need to find a way around this to increase adoption and simplicity.
I think just a basic list on github, with some form of governance should suffice, and sbt (via a simple plugin for this purpose) and other tools are just look onto that to stay updated.
It’s a bit apples-and-oranges, IMO. Different ecosystems think about this differently, and the JVM world long, long ago settled on Maven coordinates as the way to do things; Scala picked it up from there.
Frankly, I prefer the Maven approach – it’s a richer namespace, so that you don’t have as much risk of namespace collisions, and it works better with the reality that we often have lots of fine-grained artifacts in open-source projects. Projects often have hierarchy, and there’s real value in being explicit about that.
Turning this the other way: what would the benefit of a ten-thousand-line-long list be, over what we get from Scaladex?
Can you given an example of an existing name collision (and it’s possible to prevent collision via proper governance)?
Even if I have completely different namespace, do you think it’s appropriate for me to create a new library named cats? From my perspective all that richness is TMI.
Name clashes aren’t that uncommon in rich ecosystems like the JVM’s one. A typical example are forks.
Let’s say there is a lib named Foo published as com.company:foo and I forked this project. For many reasons (original project inactive, very opiniated changes etc…) I want to publish this fork independently, I can just use my own namespace: me.iltotore:foo.
The enforcement should be in the name allocation. No collisions and no name hogging for a non-existent library. Who enforces that’s a good question and it’s related to where this list will take place.
In any case, what I’m imagining is this list to co-exist with the current flow, but a way for you (and all the beginners that come into Scala) to refer to the short names. Nothing should stop you from referring the full name space, but I think also enabling the short names will be very helpful.
I don’t think there’s anything preventing someone from creating such a thing (along with an sbt plugin to use it), but I honestly don’t think it would make as much difference as you do, and I’m skeptical about it catching on enough to be useful…
There’s a well-known “name squatting” problem with ecosystems like Rust’s, where people take ownership of tons of names to “reserve” them. So many projects are just spam because of this.
I know it’s too late unless we introduce a “legacy” namespace, but I wish Cargo had gone with namespaced packages, with a reserved / curated top-level namespace, taking the place of rust-lang-nursery and augmented with well-recognized and supported community projects. There could even be a formal auditing process for these packages, code / documentation / licensing standards, etc.
I kinda wish crate names were namespaced under a username.
If we don’t want this to happen, we’ll need a system for controlling and curating these things. That sounds like a huge hassle that the community/Scala Center probably doesn’t have the bandwidth for, given how little the actual gains are.
Also worth nothing that while npm (in the JavaScript ecosystem) historically did not have namespaces, they have been added in recent years (in the form of scoped packages, like @org/foo) much for the same reasons
Follow-up, it turns out that the correct syntax actually is latest.stable (there is also latest.release that includes betas/RCs/… and latest.snapshot).
you mean like how npm governs their eco-system?
remember kik and left-pad?
Maybe it’s just me, but I don’t like the pip/npm/… approach.
No thank you. I prefer maven namespaces.
Regarding linux, the situation is a bit better.
If you use e.g. ubuntu, it’s predefined to use the ubuntu repositories, and if you want to publish something of your own, you’ll need a new PPA for that.
This is somewhat analogous to maven’s organization ID namespace.
And it’s much more of a hassle to add a new PPA then just paste a full maven dependency in the build file.
And if you want something “official” in the ubuntu repo, it is often very outdated.
Not sure you want that either…