@evan is there a reason this isn’t a wiki? I believe the intent of posts in this category to be wikis to facilitate crowd-sourcing.
Fixed, it’s now a wiki
We should include a prerequisite state of your project section at the beginning of this:
“You should be using setuptools in your project. You should be able to run
python setup.py bdist_wheelwithout errors. If either of these are not true, please consult the setuptools documentation.”
lol, and I’m not sure why it’s incorrectly wedged in my brain given no shortage of personal projects using it. Thanks, fixed.
@evan @degville Many Python applications require UTF-8 support but this requires workarounds due to the longstanding issue of poor locale support in snapd.
Many people encounter this issue and cook up their own solution to it so it might be best to document it and provide a best-practice solution.
The least intrusive and most generic solution is to add the following bits to the
LC_ALL: "C.UTF-8" LANG: "C.UTF-8"
This also works for non-python applications.
Where should I document this?
Also, a few more comments on this page:
It’s best to start a snap with the confinement in warning mode, rather than strictly applied. This is indicated through the devmode keyword. When a snap is in devmode, runtime confinement violations will be allowed but reported. These can be reviewed by running journalctl -xe.
- What is “warning mode”? Is this “devmode” confinement?
- It would be ideal if this part contained a link to more in-depth documentation on confinement.
It’s also useful to point to more resources about debugging the build on this page, like the “iterating without rebuilding” part of debugging: https://docs.snapcraft.io/debugging-building-snaps/6274
This is a great guide, but I recommend linking to somewhere next at the bottom of the page. As someone reading the document, it feels slightly disorientating to be told to “Continue”, but having no indication as to where the content is that is being referred to.
Continue on to learn how you can bundle your app’s dependencies, such as system libraries, into this snap so your app is portable across Linux distributions.
Which effectively disables the I18N. I have written a launcher remote part to solve this issue at my end: [OBSOLETED] The locales-launch remote part
I confirm this fixes the issue I mentioned, with the added benefit that localization now actually works!
I just hit this as well, a link to where you’re meant to proceed to would make this a lot less frustrating.
When working on Ubuntu 18.04 and more, you should use the multipass VM to build the snap. You should also add
base: core18 in the yaml file.
I’m trying to create my first snap and finding that it’s very difficult to figure out what I’m supposed to do to make things work as expected. Some of the documentation that I’ve read, in particular, is far less than helpful for me. On one particular document (https://snapcraft.io/docs/python-apps), I’ve decided to point out something I found that I think could be clearer to novices like myself if worded a little differently. I don’t know who updates the text of the document, but the link at the foot of it sent me to this forum.
The base keyword defines a special kind of snap that provides a run-time environment with a minimal set of libraries that are common to most applications. They’re transparent to users, but they need to be considered, and specified, when building a snap.
Does this passage tell me that “core18” is “a special kind of snap that provides a run-time environment with a minimal set of libraries that are common to most applications. They’re transparent to users, but they need to be considered, and specified, when building a snap.”?
Or does this passage tell me that, if I include “base: core18” in my app’s YAML file, then my own app is “a special kind of snap that provides a run-time environment with a minimal set of libraries that are common to most applications. They’re transparent to users, but they need to be considered, and specified, when building a snap.”?
I’d recommend altering the text to make this point more clear. Thanks!
Thanks for your feedback, and for taking the trouble to leave your comments. The documentation is generated automatically from the contents of this forum, where anyone can edit, so the docs are the result of a snap-team/community effort.
I can totally see what you mean here. I’ll reword this, and elsewhere where this paragraph is used, to make it more explicit. It should also link to our Base snap documentation, and we really should go through these tutorials to help make them easier to understand and more consistent with some of the snap/snapcraft changes that have been implemented since they were written.
This doc assumes
- The developer knows what setuptools is
- The developer has a functioning setuptools configuration
This is not the case if a developer just created a python script and wants to put it into a snap. Maybe we need multiple tutorials for python? One for setuptools and one without setuptools?
That user wrote this documentation after struggling with this page.
I ran into the same issues as the user you mentioned. The current docs really don’t state that using setuptools is mandatory.
Are there plans of updating these docs or is there some Bug tracker besides this thread to file feedback?
thanks for flagging this - I’ll go through the tutorial and update it.
Just noticed that the snapcraft.yaml file presented here does not exactly match what is grabbed from the git repo for this example. In the repo, confinement is “strict”, and the override-pull scriptlet does a “set-version” as well. Someone should make sure this page is sync’ed with that is in the repo.
Thanks for raising this. I didn’t want to introduce too many concepts into this guide that might get in the way of building the snap. I’ll update the doc to mention this discrepancy.