Scaladex badge that supplies info on supported Scala versions #659
Comments
|
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. |
Badge per platform (JVM, JS, Native) is a very good idea! 👍 |
|
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. |
Sure, I'll take a look 👍 |
|
I think, to work on this PR I'll need to be able to run Scaladex locally, as described in
... @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. |
|
Scaladex has failed to find a docker environment to start elasticsearch:
In my case it was easier to install docker on my machine. |
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)
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)
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? ```
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? ```
-green.svg){kind=link}
-green.svg){kind=link}
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)
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? ```
As a user of Scala libraries, when I come to a project on GitHub I want to know:
As a developer of Scala libraries, I know that keeping the information up to date in the the GitHub
ReadMe.mdis 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:
(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:
(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:
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:
2.10.0-RC2 (Scala 3.0.0-RC3, 2.13, 2.12 - JVM & JS 1.x+0.6)- full example forplay-json: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.
The text was updated successfully, but these errors were encountered: