Re: Input needed: Plan for packaging scala

[Ricardo Wurmus]

Hi Katherine,

it’s great that you want to take on Scala!

I’ve done a bit of work in the past to get some Java things packaged and
had to stop when I realised that nobody in the Java world seems to build
dependencies from source.  This makes it very hard for us to construct
proper dependency graphs for Java packages.

This is the primary reason why we only have a handful of Java packages
in Guix.  We don’t want to make an exception for Java and accept
pre-built binaries just to increase the number of packages.  (Luckily
for us, Java build artifacts are often quite portable, so there’s not as
much urgency to make it work with Guix as there is for applications
written in other languages.)

The same applies to build systems other than ant.  Maven cannot be built
without Maven, and its dependencies have dependency cycles.  I’ve been
using the ant-build-system’s feature to generate a default build.xml to
build some of these dependencies that would usually require Maven to
build them.  I’m not currently working on Java packaging (though I still
have a couple of patches that are almost ready).

>> It seems you already did the hard work of finding out how to bootstrap
>> Scala. (I think that writing the package definitions is the easy
>> part. Finding the Scala versions that can be compiled by Java and then
>> compile the correct newer Scala version using it is the hard part)
>
> Looks like not quite! After speaking to some friendly scala community
> members, it looks[1] like the bootstrapping process is much more
> harrowing. The last version of scala which only used Java to compile was
> pre 2.0 (for reference the 2.0 commit appears to be here[2]). So we'd be
> looking at a chain of scala packages numbering possibly in the hundreds
> and going back 10+ years.

Oof!  Looking at the latest build.xml in the legacy-svn-scala repository
the build requires a couple of jars that we don’t have in Guix.  These
(and their dependencies, recursively) would have to be built from source
first.  This alone would be a very demanding task.

If we were able to build a version of the Scala compilers and libraries
that does not require sbt it is unclear whether this would be a viable
path towards a modern version of the language.  Sadly, these
bootstrapping problems are very common, which prompted some of us to
start the Bootstrappable Builds project:

    http://boostrappable.org (temporarily offline)

> For the aforementioned reasons, I'm going to start by just packaging the
> source of sbt v0.13, but also the pre-built binary. This should help us
> at least bootstrap scala in a sane way, if not immediately
> sbt. Hopefully this still sounds OK?

sbt (even at version 0.13) is written in Scala, so maybe it would be
better to package a version of the Scala libraries and an implementation
of scalac first.  Or does sbt provide the complete toolchain?

Are you aware of any other implementation of the Scala toolchain that we
might be able to use for bootstrapping purposes?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net