Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scaladex badge that supplies info on supported Scala versions #659

Closed
rtyley opened this issue Apr 25, 2021 · 7 comments · Fixed by #660
Closed

Scaladex badge that supplies info on supported Scala versions #659

rtyley opened this issue Apr 25, 2021 · 7 comments · Fixed by #660

Comments

@rtyley
Copy link
Contributor

rtyley commented Apr 25, 2021

As a user of Scala libraries, when I come to a project on GitHub I want to know:

  • what's the latest version of Scala that it supports, and the corresponding artifact version
  • ...when I'm not on the latest version of Scala, what's the latest available artifact version for that legacy version of Scala

As a developer of Scala libraries, I know that keeping the information up to date in the the GitHub ReadMe.md is a bit of a drag. It would be lovely to have a modified badge that conveys all that information, and does so automatically.

Current Scaladex badge

As detailed on the Scaladex FAQ: Latest version
(image url: https://index.scala-lang.org/playframework/play-json/play-json/latest.svg)

New badge format

I'd like to suggest a modified larger badge that, beyond the latest artifact version, tells us the important Scala-version-dependent information, like this: Latest version
(image url: https://img.shields.io/badge/scala--textmatching-2.5%20(Scala%202.13%2C%202.12)%2C%202.4%20(Scala%202.11)%2C%202.1%20(Scala%202.10)-green?logo=scala&logoColor=DE3423)

The goal is for the badge to be human readable, give salient but not comprehensive information, keeping the label as concise as possible!

Given an artifact id, minus the Scala version suffix:

  1. Group all artifact versions by Scala binary version. If there are pre-release versions (M3, RC2) of a Scala Binary version, only use the most recent one- and if a stable version is available, only list that.
  2. Find the latest artifact version for each Scala binary version. Sort the artifact versions into descending order
  3. Against each artifact version, list the Scala binary versions supported by it (again, sorted in descending order). If the Scala binary version is supported by a more recent artifact version, don't bother to list it against older ones.

Non-JVM artifacts

If a project cross-builds to Scala.js or Scala Native, there's a lot more to explain, and the badge gets bigger. If, for this badge at least, the focus is the Scala version, rather than supported runtime, we could still add in some runtime summary:

  • If a project supports non-JVM artifacts, add a summary for the latest artifact at each Scala version - eg 2.10.0-RC2 (Scala 3.0.0-RC3, 2.13, 2.12 - JVM & JS 1.x+0.6) - full example for play-json:

Latest version

I realise that badges can be put in a lot of different places, but personally I've only ever wanted to stick them at the top of GitHub ReadMe markdown documents, where there's usually plenty of room for a larger badge.

@lefou
Copy link

lefou commented Apr 25, 2021

Wow, that's a rather large badge. How about providing multiple badges (per platform) to avoid merging too much info into one badge? It's not only the length, but also small font and the low contrast which makes a too long badge hard to read and even harder to quickly find the wanted info.

@rtyley
Copy link
Contributor Author

rtyley commented Apr 25, 2021

How about providing multiple badges (per platform) to avoid merging too much info into one badge?

Badge per platform (JVM, JS, Native) is a very good idea! 👍

@adpi2
Copy link
Member

adpi2 commented Apr 26, 2021

Thanks for opening this request! I also think that having one badge per platform is a good idea.

If by any chance someone is willing to implement that feature, it would help us a lot. A good entrypoint is here.

@rtyley
Copy link
Contributor Author

rtyley commented Apr 26, 2021

If by any chance someone is willing to implement that feature, it would help us a lot.

Sure, I'll take a look 👍

@rtyley
Copy link
Contributor Author

rtyley commented Apr 26, 2021

I think, to work on this PR I'll need to be able to run Scaladex locally, as described in CONTRIBUTING.md - unfortunately, I get several errors following those steps (full console log is here: https://gist.github.com/rtyley/a3b4c85edbd57066594ddbf11664bbc7):

data 12:55:50.119 [main] WARN o.t.u.TestcontainersConfiguration - Attempted to read Testcontainers configuration file at file:/home/roberto/.testcontainers.properties but the file was not found. Exception message: FileNotFoundException: /home/roberto/.testcontainers.properties (No such file or directory)
data 12:55:50.126 [main] INFO o.t.utility.ImageNameSubstitutor - Image name substitution will be performed by: DefaultImageNameSubstitutor (composite of 'ConfigurationFileImageNameSubstitutor' and 'PrefixingImageNameSubstitutor')
data 12:56:20.729 [main] INFO o.t.d.DockerMachineClientProviderStrategy - Found docker-machine, and will use machine named
data 12:56:20.752 [main] ERROR o.t.d.DockerClientProviderStrategy - Could not find a valid Docker environment. Please check configuration. Attempted configurations were:
data 12:56:20.753 [main] ERROR o.t.d.DockerClientProviderStrategy - UnixSocketClientProviderStrategy: failed with exception TimeoutException (Timeout waiting for result with exception). Root cause IOException (native connect() failed : Permission denied)
data 12:56:20.753 [main] ERROR o.t.d.DockerClientProviderStrategy - DockerMachineClientProviderStrategy: failed with exception ShellCommandException (Exception when executing docker-machine status ). Root cause InvalidExitValueException (Unexpected exit value: 1, allowed exit values: [0], executed command [docker-machine, status, ], output was 122 bytes:
data Docker machine "" does not exist. Use "docker-machine ls" to list machines. Use "docker-machine create" to add a new one.)
data 12:56:20.753 [main] ERROR o.t.d.DockerClientProviderStrategy - As no valid configuration was found, execution cannot continue
data 12:56:20.757 [main] ERROR ch.epfl.scala.index.data.Main$ - fatal error

... @adpi2 does any obvious fix jump out at you from those errors? The name of the docker machine name seems to be blank, which can't be good.

@adpi2
Copy link
Member

adpi2 commented Apr 26, 2021

Scaladex has failed to find a docker environment to start elasticsearch:

  • Do you have docker installed locally? Does your user have the right to start a container?
  • Otherwise, do you have docker-machine installed? Have you defined a default machine?

In my case it was easier to install docker on my machine.
If you don't want to use docker you can start elsaticsearch by yourself and modify the Scaladex configuration.

rtyley added a commit to rtyley/scaladex that referenced this issue May 2, 2021
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
The refactor in this commit is driven by the work in the subsequent
commit for issue scalacenter#659 (creating a Scaladex badge that supplies
concise info on supported Scala versions). The key word there is
'concise' - given the many Scala artifacts that can be published for
a single artifact version (the matrix of Scala language version, the
platform - Scala JS/Native/SBT - and the platform version), achieving
a concise summary requires a lot of grouping.

Grouping by Scala `LanguageVersion` was easy enough, but grouping by
platform & platform version was harder, as there wasn't any existing
class to represent that. Consequently, I introduced the concept of a
'platform edition' (eg 'Scala JS 0.6', or 'Scala Native 0.4'), which
is composed of two values:

* targetType (Scala JS, Scala Native, or SBT)
* platform version (eg the version '0.6' or '1.0' of Scala JS)

...this is like a `ScalaTarget`, but without the Scala Language
version that `ScalaTarget` includes (eg a `ScalaTarget` is
specifically compiled for, eg, _Scala 2.11_ on Scala JS 0.6).

Having introduced the concept of `PlatformEdition`, it made sense to
redefine relevant `ScalaTarget`s in terms of that - to do this meant
moving several ad-hoc methods from the companion objects of
`ScalaTarget` implementations (ie `ScalaJs`, `ScalaNative`,
`SbtPlugin`) to the corresponding `ScalaTargetType` implementations
and making them more widely available, by declaring them in the
`PlatformVersionedTargetType`. This removed duplication of this code:

* producing a String `render` value for platform names
* checking validity of platform versions.

A lot of repetition was removed, and in fact most of the `ScalaTarget`
companion objects were now empty and could be deleted.

Another smaller change was prompted by the upcoming need to identify
a `ScalaTargetType` by name (when the user specifies it as a query
string parameter). To do that, you need a full list of
`ScalaTargetType`s, and then you can also use that list to create an
`Ordering[ScalaTargetType]`

Also tidied up various tests that were creating their own platform
version constants (as I was already moving equivalent constants from
`ScalaTarget` companion objects to `ScalaTargetType` objects)
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
The refactor in this commit is driven by the work in the subsequent
commit for issue scalacenter#659 (creating a Scaladex badge that supplies
concise info on supported Scala versions). The key word there is
'concise' - given the many Scala artifacts that can be published for
a single artifact version (the matrix of Scala language version, the
platform - Scala JS/Native/SBT - and the platform version), achieving
a concise summary requires a lot of grouping by those properties.

Grouping by Scala `LanguageVersion` was easy enough, but grouping by
platform & platform version was harder, as there wasn't any existing
class to represent that. Consequently, I introduced the concept of a
'platform edition' (eg 'Scala JS 0.6', or 'Scala Native 0.4'), which
is composed of two values:

* targetType (Scala JS, Scala Native, or SBT)
* platform version (eg the version '0.6' or '1.0' of Scala JS)

...this is like a `ScalaTarget`, but without the Scala Language
version that `ScalaTarget` includes (eg a `ScalaTarget` is
specifically compiled for, eg, _Scala 2.11_ on Scala JS 0.6).

Having introduced the concept of `PlatformEdition`, it made sense to
redefine relevant `ScalaTarget`s in terms of that - to do this meant
moving several ad-hoc methods from the companion objects of
`ScalaTarget` implementations (ie `ScalaJs`, `ScalaNative`,
`SbtPlugin`) to the corresponding `ScalaTargetType` implementations
and making them more widely available, by declaring them in the new
`PlatformVersionedTargetType` trait, removing duplication for this
existing code:

* producing a String `render` value for platform names
* checking validity of platform versions.

As result most of the `ScalaTarget` companion objects were now empty
and could be deleted.

Another smaller change was prompted by the upcoming need to identify
a `ScalaTargetType` by name (when the user specifies it as a query
string parameter). To do that, you need a full list of
`ScalaTargetType`s, and then you can also use that list to create an
`Ordering[ScalaTargetType]`

Also tidied up various tests that were creating their own platform
version constants (as I was already moving equivalent constants from
`ScalaTarget` companion objects to `ScalaTargetType` objects)
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
Fixes scalacenter#659 - adding
support for a badge that summarises, for a given artifact, which versions
of Scala it supports (and what the latest artifact version is for each
of those Scala versions).


```
$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10)-green.svg?

$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10)-green.svg?
```
rtyley added a commit to rtyley/scaladex that referenced this issue May 3, 2021
Fixes scalacenter#659 - adding
support for a badge that summarises, for a given artifact, which versions
of Scala it supports (and what the latest artifact version is for each
of those Scala versions).


```
$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10)-green.svg?

$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg?targetType=Js | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10_--_Js_0.6)-green.svg?
```
@rtyley
Copy link
Contributor Author

rtyley commented May 3, 2021

I've opened a PR at #660 to add the new badge (with separate badges for different platforms, as suggested by @lefou).

adpi2 pushed a commit that referenced this issue May 11, 2021
The refactor in this commit is driven by the work in the subsequent
commit for issue #659 (creating a Scaladex badge that supplies
concise info on supported Scala versions). The key word there is
'concise' - given the many Scala artifacts that can be published for
a single artifact version (the matrix of Scala language version, the
platform - Scala JS/Native/SBT - and the platform version), achieving
a concise summary requires a lot of grouping by those properties.

Grouping by Scala `LanguageVersion` was easy enough, but grouping by
platform & platform version was harder, as there wasn't any existing
class to represent that. Consequently, I introduced the concept of a
'platform edition' (eg 'Scala JS 0.6', or 'Scala Native 0.4'), which
is composed of two values:

* targetType (Scala JS, Scala Native, or SBT)
* platform version (eg the version '0.6' or '1.0' of Scala JS)

...this is like a `ScalaTarget`, but without the Scala Language
version that `ScalaTarget` includes (eg a `ScalaTarget` is
specifically compiled for, eg, _Scala 2.11_ on Scala JS 0.6).

Having introduced the concept of `PlatformEdition`, it made sense to
redefine relevant `ScalaTarget`s in terms of that - to do this meant
moving several ad-hoc methods from the companion objects of
`ScalaTarget` implementations (ie `ScalaJs`, `ScalaNative`,
`SbtPlugin`) to the corresponding `ScalaTargetType` implementations
and making them more widely available, by declaring them in the new
`PlatformVersionedTargetType` trait, removing duplication for this
existing code:

* producing a String `render` value for platform names
* checking validity of platform versions.

As result most of the `ScalaTarget` companion objects were now empty
and could be deleted.

Another smaller change was prompted by the upcoming need to identify
a `ScalaTargetType` by name (when the user specifies it as a query
string parameter). To do that, you need a full list of
`ScalaTargetType`s, and then you can also use that list to create an
`Ordering[ScalaTargetType]`

Also tidied up various tests that were creating their own platform
version constants (as I was already moving equivalent constants from
`ScalaTarget` companion objects to `ScalaTargetType` objects)
adpi2 pushed a commit that referenced this issue May 11, 2021
Fixes #659 - adding
support for a badge that summarises, for a given artifact, which versions
of Scala it supports (and what the latest artifact version is for each
of those Scala versions).


```
$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10)-green.svg?

$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg?targetType=Js | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10_--_Js_0.6)-green.svg?
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants