Add a plugin for running simple shell scripts

[LefterisJP]

LP: #1536624

[kyrofa]

s/on which/into which/

[kyrofa]

2016

[kyrofa]

@LefterisJP thanks for the PR! Please make sure you sign the CLA.

[kyrofa]

s/result/s/results/.

[kyrofa]

run() accepts an argument to set the working directory-- I suggest using that.

[LefterisJP]

@kyrofa We signed the CLA as a company/team with launchpad ID slock.it.

But before merging there is one more thing that needs adressing from what I see. My tests pollute the stdout when you do ./runtests.sh. This needs fixing.

[kyrofa]

@LefterisJP ah, that means my checker script needs updating! Thanks for that.

Yeah, on your tests you can mock stdout, like this test.

[LefterisJP]

@kyrofa All right done, thanks for the link. Nothing shows up when running the tests now.

[elopio]

There was some discussion about this in the mailing list and the conclusion, iirc, was that it promotes a style for packaging that we want to avoid with snapcraft. I can't find the link now, so my memories might be wrong. @sergiusens should remember better.

[LefterisJP]

@elopio This plugin is meant as a last resort if none of the other plugins can do what you want at the moment and/or if you want something very specific done.

The more advanced snapcraft becomes, especially around the intricacies of providing cross-compiled binaries for different architectures the less useful such a plugin will be. But we are not there yet.

And for the here and now I can definitely see use cases for it. I have one in a snap I am working on right now for example.

[sergiusens]

this feels specific to a certain script and not generic enough.

[sergiusens]

The plugin looks ok, but it does feel very specific to a use case and not generic enough for reuse.
Is the first argument for the script always the destination dir?

I personally believe we lack convention for this to work for everyone so maybe if it is used to build a specific thing, call the plugin thing. Or if you want more autonomy, let me propose this layout:

snapcraft.yaml
parts/plugins/
                   x-script.py

Where script.py is the plugin proposed here and in snapcraft.yaml just put in plugin: script.

Am I sounding reasonable or am I missing the obvious?

[LefterisJP]

Hello @sergiusens . Your proposed layout is what I am currently using in my project. It works and I can keep it like that but I believe that with the minimal convention of having the first argument be the destination directory all kinds of scripts could work.

In essense a shell script can do anything if called with sudo. It can be like a generic 'way out' if you don't want to build your own custom plugin and still do your tasks cleanly with snapcraft.

Let me give three examples.

1. A project needs to download something with wget, git clone something else and combine those and create a binary which it needs to place into the install directory.

2. A project has a makefile which has to accept particular options and targets. (Currently the make plugin only runs Make, builds all targets, gives no extra options)

3. A project may need to use a tool like xgo create an LXC for a project and produce cross-compiled binaries.

There can be many more examples, since a script's nature is to be generic. In the context of snapcraft, as long as we have a destination directory of where the script should output its results while snapping the part, I think it is a generic enough plugin.

If you are afraid it's not generic enough there are 3 additions I can see:

1. Add a list of strings that would be also copied along with the script in the building directory so that the script can use them.

2. Add multiple destination directories. Make it a list of strings, so that if the creator of the script wants to place files/binaries in different places he can consume this list of destinations as he wishes, copy his results there and create his part, ready for snapping.

3. A list of strings that would count as arguments to the script. Even though this is not really needed since the user of the plugin would also be the creator of the script and he may as well just hard-code them in there.

In conclusion, I understand that probably the best way to go would be to have a wget plugin, an xgo plugin, and generally a plugin for each of the tools that one would be tempted to turn to a script for. I agree with that idea but since we are not there yet, I think it's fair to allow users of snapcraft have a generic script solution for when no plugins exist, or when the current plugins don't have enough options, or need more customization.

[sergiusens]

Hi, sorry for taking so long to take a look at your reply.

Here's my stance: Problem 1 can be solved with multiple parts and 2 is in a PR now.
Problem 3 seems to be very specific, so writing a private plugin seems a lot cleaner than a script.

I'm closing this for now; if you feel a script plugin is still important please send an email to snappy-app-devel so a wider audience can provide opinions.

[LefterisJP]

@sergiusens Too bad :(

I still think this is important but it's not my call what goes in snapcraft core. I will keep it as a local plugin on my snap then. Thank you for your time.