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
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
