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

[Didier Roche]

Le 27/10/2016 à 08:37, Didier Roche a écrit :
> Le 27/10/2016 à 01:13, Joseph Rushton Wakeling a écrit :
>> Hello folks,
> Hey Joseph,
>
> It would be great to have D support! Thanks for working on that :)
> I'm going to try to answer to some of your questions, but I'm sure
> Sergio (CCed) would be able to give deeper insights on some parts as
> being the snapcraft upstream.
>> 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?
> I would really advise going the build.sh route. Doing a custom snapcraft
> plugin as you started is definitively the right path.
> If you take other plugins having similar problematic, like Go, here is
> how they work:
> - Golang binaries (compiler tools and standard library) installs itself
> in parts/<part_name>/go. This logic is from the golang plugin itself.
> You will need in your case to ensure LDC is relocatable and can be
> downloaded and extracted this way. You can then build without depending
> on any package or distribution.
> - Then, the plugin run go build, go install, changing the paths. The
> plugin can define optional parameters that it will use then. In you
> case, I think the plugin will setup environment variables to refers to
> local LDC and standard D libraries. Then, you can have one option being
> "entry-point", which will refers in your DUB snap case to build.sh. The
> plugin would execute it.

Just a note: after a quick double checking , the snapcraft go plugin
relies on ubuntu packages (I think it should rather download latest
stable go and use GOROOT to use it). This isn't the case for other
plugins like nodejs which was the one I had in mind and I still think
you should prefer that road.

Didier