Re: Input needed: Plan for packaging scala

[Katherine Cox-Buday]

Danny Milosavljevic <address@hidden> writes:

> Hi,
>
> On Fri, 24 Feb 2017 08:39:24 -0600
> Katherine Cox-Buday <address@hidden> 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)

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.

>> 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.

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?

> 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.

I'm not, thanks for pointing that out!

[1] - 
https://issues.scala-lang.org/browse/SI-10172?focusedCommentId=76415&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-76415
[2] - 
https://github.com/scala/legacy-svn-scala/commit/d5f3f603228cb3a0cae1536dba9990a061fcded7

-- 
Katherine