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

[Sergio Schvezov]

El 27/10/16 a las 17:13, Joseph Rushton Wakeling escribió:
> On 27/10/16 08:37, Didier Roche wrote:
>> It would be great to have D support! Thanks for working on that :)
>
> Great to hear :-)
>
> Just to be clear, it's already in principle possible to package D 
> applications as snaps; DUB support isn't needed, but is very helpful, 
> because a lot of D projects do use it.
>
>> 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.
>
> Thanks very much.  I'll respond to some of your suggestions below ...
>
>> I would really advise going the build.sh route. Doing a custom snapcraft
>> plugin as you started is definitively the right path.
>
> Yes, agreed.  I was curious about the `build.sh` option not because I 
> think it's a good idea, but because I was thinking: "What if it was 
> the only build option for this project?"  I'd like to know how to 
> handle that situation if I ever encounter it in another project.
>
>> From your questions and the statement that there is no explicit install
>> steps, I think you mean that D programs just build in tree (snapcraft
>> tries to encourage builds out of trees) and then, the install step for
>> people is to copy the resulting binaries and assets manually?
>
> Yes, exactly.  It's not _entirely_ as bad as it sounds because each 
> project's `dub.json` config file can define a `targetPath` variable 
> where built programs will be placed.  The plugin can use that if 
> available.
>
>> If so, I can see 2 paths here:
>> - either you expect people to explicitely list assets and binaries that
>> should be installed (this could again be a custom option of your plugin)
>
> This is pretty much the direction I've taken for now.

The make plugin has an `artifacts` option (if you inherit from it you 
get it for free). If necessary we can move this to the base plugin or 
even as a core capability. Used for projects that are older or do not 
follow GNU conventions of having an `install` target.

>
>> - either you try to be starter, as you told, and detect extra files
>> being created in the parts/<part_name>/build. There is no built-in
>> features in snapcraft for this as far as I know, but, it would be quite
>> easy to build it as part of your plugin: list at the start of the build
>> phase files in parts/<part_name>/build and redo the same thing after the
>> build. Then, in the install phase, use that list (that you store on
>> disk) to copy newly created content in parts/<part_name>/install. Then,
>> snapcraft will pick it up from there. Note that I think you still need a
>> manual options for your users to list eventual assets (or they can use
>> the dump plugin in another part).
>
> Nice thought.  I'll try to look into that.
>
> There is a 3rd option which could be for the plugin to read the 
> `dub.json` config file of the project being built, and parse that to 
> discover the targets that will be built, but honestly that feels like 
> duplication of effort, and it would probably be better to encourage 
> the DUB developers to provide an `install` option.
>
>> If you prefer to copy everything and have your users filtering from the
>> stage area to the prime area, you can use the "snap:" stenza (don't use
>> filesets for now if you don't plan to repeat the file list name).
>
> Yup, this is the option I use now.
>
>> I would advise in a first step to consider the D compiler used by DUB to
>> build other things to be part of your snap. You want to control the
>> version in it and consider it as part of your dependencies you need in
>> your snap. We can discuss later about an interface, but I would really
>> go that way as a first step.
>
> Yup, bundling the compiler into the snap is the way I have gone as a 
> first step.
>
> However, the real issue is that DUB is supposed to provide the user 
> with the option to choose the D compiler to use.  It's tolerable as a 
> first step to just give one option bundled, but ideally the user would 
> be able to invoke DUB and specify to it any compiler they like -- 
> whether a snap-packaged one, or one installed on the host system.
>
> I was assuming that allowing the user to (optionally) specify a 
> compiler of choice via an interface would be easier to achieve, but I 
> don't know if that's true.
>
>> There is no way right now on definining new interfaces apart from
>> building them in snapd, and so, use your own local version. (That's the
>> reason why I advise you to not bother with this right now, let's take an
>> easier path first, figure the rest, and then, we can rediscuss)
>
> Well, I already took the easier path, so that's why I raised the 
> discussion of alternatives ... :-)
>
>> I would look at /var/log/syslogs. Apparmor and seccomp denials are
>> listed there. Note that if you didn't already, you should really start
>> developping your snap in devmode. That way, it will get confinment out
>> of the equasion to get your relocatable code and dependencies working.
>> Then, we can turn on confinement and figure out those issues to be able
>> to publish in the stable channel.
>
> Yea, I probably should have started with devmode.  Thanks for the 
> advice about syslogs; I'll check it out and see what I can find.

snap install snappy-debug, it will provide nice hints.

>
>> Don't make your snap calling other snap endpoints. It's better from your
>> own snap code to ensure that your local ldc2 is in your snap $PATH, and
>> call ldc2 directly (it will then use the parent process confinment
>> profile, of course). I think that will help you a little bit more to
>> control what you are calling at, and how.
>
> Well, as I said, it's less about ensuring there is a local LDC, and 
> really more about finding a way to ensure the user can get DUB to work 
> with any D compiler on their system, whether installed on the host 
> system, in another snap, or in the DUB snap itself.
>
> I definitely don't intend for the DUB snap to have a hard dependency 
> on another snap's existence, if that's what you were concerned about.
>
> Thanks again for the thoughts and feedback -- I'll look into the 
> AppArmor side of things soon.  Meanwhile, congratulations on your own 
> very nice video on snap packages! :-)
>
> Best wishes,
>
>     -- Joe
>