Why doesn't Scala have library listing?

Tooling
#1

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.

What am I missing?

4 Likes
#2

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?

3 Likes
#3

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.

1 Like
#4

Scaladex is a webcrawler. It gets its information from what exists. It’s not an enforcer.

#5

Okay, maybe I don’t entirely understand your suggestion. What should be enforced? Who should enforce it?

#6

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.

3 Likes
#7

Hunting down the latest version of a dependency when I want to try a quick test is quite burdensome.

Sometimes a project will have a convenient page showing latest tag or “if you use sbt, paste this”, but often not. IIRC scalatest does not.

It’s a real hassle.

It would be handy if sbt and repls with magic imports would just give me latest defaults. Don’t make me work for it.

Another way of putting it is, shift the burden to legacy projects that require old versions of things because they can’t keep current.

4 Likes
#8

This sort of exists, coursier recognizes a + suffix in version numbers:

% cs fetch -p 'org.scalacheck::scalacheck:1+'
/home/smarter/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scalacheck/scalacheck_2.13/1.16.0/scalacheck_2.13-1.16.0.jar:...

But for some reason you can’t write org.scalacheck::scalacheck:+, so you need to know the first digit of the version number. EDIT: I opened Allow specifying a version number as just `+` without leading digits · Issue #2408 · coursier/coursier · GitHub for this.

3 Likes
#9

Note that Scaladex provides this.

4 Likes
#10

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.

#11

If the python ecosystem and the linux package distribution systems make due, I believe Scala can as well.

#12

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…

2 Likes
#13

I think it would be very convenient and very cool if scala-cli could search Scaladex.

Someone opened a ticket already with that idea, here: Add command to search for dependencies by andrelfpinto · Pull Request #871 · VirtusLab/scala-cli · GitHub

5 Likes
#14

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.

See: https://www.reddit.com/r/rust/comments/9aaanw/cargo_crate_name_reservation_spam/

The first comment argues (emphasis mine):

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.

A more recent discussion: https://www.reddit.com/r/rust/comments/dzlksz/proposal_for_cratesio_crate_name_reservation/

First comment again:

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.

6 Likes
#15

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

2 Likes
#16

I think it would be very useful for both beginners and experienced users

From the current discussion, my ideal option would be:

  • A designated entity has a mapping from short to full names
  • Full and short names can both be used anywhere
  • When using a short name, the entity is queried for the corresponding full name
  • The entity makes sure outdated libraries are replaced in the mapping by up-to-date forks
  • If no version number is mentioned, take the latest (stable) one

Now which entity is best ?
That I’m not sure yet, but scaladex seems like the obvious solutions, as it is very similar to it’s intended purpose