Provisional snap for DUB (D language package/build manager)

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Wed Oct 26 23:13:38 UTC 2016


Hello folks,

Following my attempt to create a snap for LDC (LLVM-based compiler for the D 
programming language), I thought I'd have a go at another D-related project and 
snap DUB.  This is a package/build manager that's popular in the D community, 
and so having it available as a snap could be very useful.

First caveats: this is a command-line developer tool, so some of the same 
limitations are going to apply as were identified with the LDC snap (access to 
system tools, linking against host-system development libraries, etc.).  I also 
had to take some temporary shortcuts to ensure that the packaged DUB had a D 
compiler available.

The draft package is available here:
https://github.com/WebDrake/dub.snap/pull/1/files

A few things on what went into it, and corresponding requests for feedback.

First: DUB can be built two ways; either by calling a shell script, `build.sh`, 
or by DUB itself via an existing install.  I couldn't identify an obvious way to 
handle the former, so (given that DUB is packaged in Ubuntu 16.04) I opted to 
create a `dub.py` snapcraft plugin.

I'm not a Pythonist myself, so any feedback on that code would be welcome.  But 
I have a couple of other questions:

   * Is there any way for the plugin to ask for a `dub` instance to be available?
     Currently I'm just specifying `dub` as a build dependency in addition to the
     plugin.

   * Assuming I'd wanted to go the `build.sh` route, is there any way I could
     have achieved that with existing plugins?

DUB doesn't have an `install` option, only a `build` one, which creates some 
problems in terms of determining what files go into the snap.  I compromised on 
a short term workaround where the plugin copies everything in the `build/` dir 
of the part being built, and the user is expected to manually specify what bits 
of that should actually wind up in the final snap.  If there is a target path 
where the built files are placed, the plugin can handle that, too.

Two questions there, too:

   * Is there any way to filter that stuff out already at the staging area
     or earlier?  I tried using `filesets:` but didn't have much luck.

   * Is there any way to detect what extra files have been created after the
     build completes and just use those?

Since DUB needs a D compiler to be able to build anything, I first tried to just 
use the existing Ubuntu `ldc` package, and then reverted to copying the entirety 
of my LDC snap setup because it proved simpler to get working.  That's very much 
a temporary measure, I hope, but again, questions here:

   * Is there any way for me to give the DUB snap access to the ldc2 and/or
     ldmd2 installed in my LDC snap package, other than explicitly defining a
     `d-compiler` interface and submitting it to `snapd`?

   * Is there any way of defining/using/testing an interface short of building
     my own local snapd?

The last issue is a bit weird: DUB installed by the current snap package can 
build D projects, but exits with an error: "Bad System Call".  It's been 
difficult to track down what was going on here (`strace dub build` for example 
was not very edifying, presumably because of the containerization) so any advice 
on how to identify what's wrong?

At a guess, it's related to the step where the built binaries are made 
executable, because they get created, but are _not_ executable at the end of the 
process.  This is a bit of a surprise, because the standalone LDC snap doesn't 
have this issue (things get made executable just fine).

I did try making ldc2 and ldmd2 apps of the DUB snap too, but that seemed to 
make no difference.  OTOH that might be related to how the snap-packaged DUB 
would invoke the D compiler (because presumably you'd need to call `dub.ldc2` in 
order to ensure that you get the `home` plug working properly, while DUB 
probably calls `ldc2` directly).  Anyway, any thoughts on what could be going on 
here?

Thanks in advance for any advice or thoughts, and best wishes,

     -- Joe




More information about the Snapcraft mailing list