| 2018-01-31 04:27:40 |
Brett Sutton |
description |
Not certain if this is a bug, a design flaw or a documentation issue (but I think its actually all of the above).
I started building a snap with a directory:
<project>
- snap
- snapcraft.yaml
I was in the habit of building the snap by running snapcraft from the 'snap' directory.
This worked fine and I was able to build and install my snap.
I then added a hook directory under the snap directory
<project>
- snap
- snapcraft.yaml
- hooks
- install
- configure
When I ran snapcraft it built the project without any errors.
When I went to install the snap the following error was displayed:
snap try --devmode prime
error: cannot perform the following tasks:
- Run configure hook of "pi-gation" snap if present (run hook "configure": cannot snap-exec: no such file or directory)
As an aside:
The error is particularly unhelpful as it didn't output the path it couldn't find. I would have found the problem much sooner if the error message was better.
So I eventually worked out that I have to run snapcraft from the <project> directory or else it wouldn't find the hooks.
This then caused a secondary problem in that when I started building the snap from the <project> directory the rest of the paths in snapcraft.yaml stopped working as it appears that they are taken to be relative to the directory you run the build from.
So snapcraft clearly allows you to run it from a variety of locations but clearly it only works when you run it from the projects directly.
I think we would be much better off if the system was prescriptive as to where you run snapcraft from.
When you run snapcraft it should check for the 'snap' directory in the current working directory.
It should then check if the snapcraft.yaml exists in that snap directory.
If either of these two conditions are not met the snapcraft should bail with an appropriate error.
I would suggest that this will save many developers hours of fine trying to find out why their hooks arn't found.
There is a chance that this might break some existing snap builds (due to the above noted relative path issue) but given that most snaps will have a hooks directory I think this risk should be fairly minimal.
Regards,
Brett |
Not certain if this is a bug, a design flaw or a documentation issue (but I think its actually all of the above).
I started building a snap with a directory:
<project>
- snap
- snapcraft.yaml
I was in the habit of building the snap by running snapcraft from the 'snap' directory.
This worked fine and I was able to build and install my snap.
I then added a hook directory under the snap directory
<project>
- snap
- snapcraft.yaml
- hooks
- install
- configure
When I ran snapcraft it built the project without any errors.
When I went to install the snap the following error was displayed:
snap try --devmode prime
error: cannot perform the following tasks:
- Run configure hook of "pi-gation" snap if present (run hook "configure": cannot snap-exec: no such file or directory)
As an aside:
The error is particularly unhelpful as it didn't output the path it couldn't find. I would have found the problem much sooner if the error message was better.
So I eventually worked out that I have to run snapcraft from the <project> directory or else it wouldn't find the hooks.
This then caused a secondary problem in that when I started building the snap from the <project> directory the rest of the paths in snapcraft.yaml stopped working as it appears that they are taken to be relative to the directory you run the build from.
So snapcraft clearly allows you to run it from a variety of locations but clearly it only works when you run it from the projects directly.
I think we would be much better off if the system was prescriptive as to where you run snapcraft from.
When you run snapcraft it should check for the 'snap' directory in the current working directory.
It should then check if the snapcraft.yaml exists in that snap directory.
If either of these two conditions are not met then snapcraft should bail with an appropriate error.
I would suggest that this will save many developers hours of fun trying to find out why their hooks aren't found.
There is a chance that this might break some existing snap builds (due to the above noted relative path issue) but given that most snaps will have a hooks directory I think this risk should be fairly minimal.
Regards,
Brett |
|
