Generally speaking, it’s a bad idea to issue a command to install python packages using pip from within the directory of a python project that has a setup.cfg. The reason is that the local setup.cfg will be applied to whatever you’re trying to install, which can easily case an error.
This is a problem for snapcraft because when a python project has multiple python packages as dependencies, at the install stage the project’s setup.cfg is wrongly being applied to all the python packages.
I’m running into this problem with my project’s build. When running snapcraft, it attempts to install all the dependencies and the main program itself at the same time (my project is in bold):
Resulting in this exception: distutils.errors.DistutilsOptionError: error in setup.cfg: command 'build' has no such option 'i18n'
The problem here is that my project setup.py does things like build translations, icons etc., which are specified in the setup.cfg. These specifications should not be applied to the program’s python dependencies too. It seems to me that this is a bug in snapcraft.
This is a weird situation because, on purpose, we run all the build commands from the build directory. And if you have a setup.cfg in that build directory, python goes all crazy.
Patching snapcraft like this:
works for your snap. We would have to be careful to check if it works for everything. And I have no idea what would be a good cwd, instead of builddir. I just used the packages dir, but no reason for that.
I got snapcraft from git, applied the patch, and ran it as described in snapcraft’s HACKING.md. While still in the venv, unfortunately I got the same build error as before. which snapcraft confirms I’m running the version from git. Perhaps I’m doing something wrong?
I don’t think I did. Today I started afresh and made sure to include the flag, and now happily the snap builds using the patched snapcraft. Now I just need to figure out why the resulting snap doesn’t start!
Given the build now works, perhaps your patch is a good solution? I can’t think of any unwanted side effects of doing it like that.
Thanks for trying it @damonlynch. Can I interest you in proposing this fix in a pull request to snapcraft, so we can discuss it in github? It will need a few tests to make sure we don’t regress. We can give you a hand in rocket.ubuntu.com, our community of contributors is growing there.
Sure, but please keep in mind I’ve never used git for anything other than git clone (or git apply), and I’ve never made a pull request on github. So a little handholding might be in order – apologies for that!
That’s right. Next week when you have a little time come to the channel in rocket, and we’ll give you some simple commands that you can follow to keep your git workspace in a sane and simple way.
I always recommend people to start with the free parts of this course, that is a good and interactive way to jump into git:
sorry to be the necromancer here. I found this because I had hoped to already find this tool all snapped and such.
I see the snapcraft.yaml file is still present in the last commit, but since I’m on debian unstable and currently waiting for the newest (hopefully non-broken) version of snapd I cannot build it…
Sorry, I am unsure. My workaround to the problem was to remove the setup.cfg from my project. (Alas I still don’t have a working snap, but that’s due to other issues).
