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