Re: Input needed: Plan for packaging scala

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi,

On Fri, 24 Feb 2017 08:39:24 -0600
Katherine Cox-Buday <cox.katherine.e@gmail.com> wrote:

> So, to untangle this knot to achieve reproducibility, I was planning on
> first packaging scala 2.9.2, then the latest version of sbt that could
> be built with scala, then sbt 0.13 (which would be useful in its own
> right as a package), and then finally scala 2.12.1.

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)

> The build for scala 2.9.2 attempts to pull some libraries from a remote
> source, so I'm assuming I'll need to also package those?

Yes please.

> I do, however, want to confirm that this is a sane plan
> before I set out on this journey. 

Sounds good.

> It would be easier if I could just do
> a binary package to bootstrap the toolchain and back-fill when I have
> more experience, but I wasn't sure if that is acceptable.

It's acceptable. You should make sure to eventually do a reproducable build - but it's OK to start with a binary package as a builder for the time being.

The question is whether it's actually easier that way. Guix uses non-standard locations (for good reasons) - so a random executable you download won't run because it won't find any libraries. The situation is not that bad if it's in Java, though - you can always specify the classpath when invoking the VM.

P.S. For storing custom package definitions, do you use GUIX_PACKAGE_PATH ? I didn't when I started out using Guix - but I should have. It's easiest to get started writing your own package definitions that way.