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

[Joseph Rushton Wakeling]

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.

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

> 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