Drop ~/.ivy2/local as a default repository

[dwijnand]

@lrytz hit an issue where he had a locally published version of "2.13.2-bin-..." for October last year, and that was what scala -213 was picking up.

The workaround is

$ scala -v -213 -C--no-default -C-r=central
[setScalaVersion] arg = '2.13+'
[addCoursier] arg = '--no-default'
[addCoursier] arg = '-r=central'
# Executing command line:
cs
launch
scala:2.13+
--no-default
-r=central
--

Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 11.0.6).

But probably better to make central the only resolver used for... -213/-212/etc... for no arguments... should the ~/.ivy2/local default be left for anything? I guess --scala-version, maybe even -<version>... 🤔

[dwijnand]

Following on from @SethTisue also hitting this (#22), this isn't due to any intention by scala-runners: it's the default behaviour of cs launch.

So, should we report it upstream to coursier as surprising behaviour? Think about it: "Would you be surprised if cs launch scala:2.13+ launched the version of Scala you locally published in October last year?" If yes, then let's report it upstream.

Otherwise we need to decide how to counter Coursier and whether it should counter it in all use cases and how that change should interact with the other options passed.

Thoughts? Ideas?

[lrytz]

My guess is that coursier will not want to change the meaning of 2.13+, as it's (I assume?) following ivy (https://ant.apache.org/ivy/history/2.1.0/settings/version-matchers.html).

So I'd change the -212 / -213 args of scala-runners to only look at maven central.

[dwijnand]

Seeing as from the range of versions that "2.13+" expands to it picks the "latest", maybe (ignoring 2.13.3 is out now) it's incorrect in picking "2.13.2-bin-..." over 2.13.2?

It's, of course, faster to make the change you're talking about, and I might just do it even if it's the lesser fix.

[lrytz]

My intuition when seeing

  -213                       use the latest 2.13.x release

is that it'll give me the latest official release, no matter what happens to be on my machine locally. The fact that it uses coursier's 2.13+ behind the scenes is an implementation detail.

[dwijnand]

OK, first of all I realised I misspoke:

it's incorrect in picking "2.13.2-bin-..." over 2.13.2

Coursier picked 2.13.2-bin-... over 2.13.1, as that was the latest release of 2.13 back in March, and as shown from the REPL banner:

Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 11.0.6).

So this also has ties with my "we should bump back baseVersion and not be publishing as x.y.{z + 1}-bin-..." argument, but I mustn't digress...

I did some digging:

• https://github.com/coursier/coursier/issues/301 isn't explicit, but seems to be ok with ~/.ivy2/local being used over remote repositories when fetching artefacts.

• https://github.com/coursier/coursier/issues/837 is more detailed (and more recent) and specifies that Coursier's defaults will sacrifice some reproducibility for less IO, specifically it's download mode / CachePolicy will use artefacts in its cache before considering remote repositories.

If I understand correctly the way Coursier works is that even if one of us does a local publish (to ~/.ivy2/local) of Scala and resolves to Coursier's cache, using -C--no-default -C-r=central shouldn't pick it, because ~/.ivy/local is no longer one of the repositories to consider. So it would do the right thing.

The strict interpretation of "no matter what happens to be on my machine locally" would be ForceDownload, but I assume you only meant "ignore publishLocals in ~/.ivy2/local" not "distrust your own cache, Coursier".

[lrytz]

I assume you only meant "ignore publishLocals in ~/.ivy2/local" not "distrust your own cache, Coursier"

Yup, absolutely!