I don't think Snapcraft is a good system

snapcraft
1

I don’t think Snapcraft is a good system and I don’t think it’s going to work out in the longterm. I attribute this mostly to it’s Sandbox.

I personally think it’s so bad that I am tempted to create a competitor.

I am hoping to start some dialog to workout how releasing software on Snapcraft got this convoluted and to see if anyone else feels the same way.

It seems fairly frequently that I see Snapcraft having significant bugs or issues, and I only login once a Month if that.

It’s not easy enough to use, it needs significant work to streamline the release of software, at minimum it needs a graphical software submission system that generates the yaml and other parts for you based on a series of selection boxes and info screens, like a software install wizard.

Some points;

  1. Supporting one git provider GitHub seems unnecessarily limiting.
  2. Snapcraft is unable to provide a level of support that matches the complexity of its software deployment system.
  3. Auto-triggering re-builds every time a git commit is pushed, is unlikely to be sustainable in the long run. I often see problems with this build system, recently ARM builds where down for over 48 hours, recently the installed snaps metric was broken for a few days, often builds take a long time, maybe reducing the load on the system by only allowing manual triggers on builds? Maybe make people specify auto build triggers in the snapcraft.yaml and have auto build trigger disabled by default?
  4. High bar to entry for beginners, no clearly listed step by step tutorials for a number of deployment options and configurations, often it’s easier to find an existing project of a similar nature deployed on Snapcraft via Google or GitHub searches and learn from how that project configured it’s snapcraft.yaml. If I want to deploy a windows application via wine for example, there is no obvious place for a novice to start without significant time investment.
  5. Review system is not great, in the past I had snaps that have reviews from before they where even released, how is that even possible? Are the timestamps for reviews based on the system local time/date of the reviewer or something? I had reviews from years before the Snap existed. All seem removed now.
  6. No incentive to actually create high quality or constructive reviews, users don’t have a reason to value their input. There needs to be more of a focus on attracting high quality reviewers to Snapcraft, it would benefit Snapcraft in external exposure as well as higher quality internal reviews which would also benefit page ranking on search engines. Snapcraft needs to be the Medium of software reviews - it needs to empower and platform critics. Any press is good press.
  7. Anyone can register a snap name and never use it, and even worse, there seems to be no way for a user to free the snap name after having claimed it. This is insanity. There needs to be at minimum a grace period to free the snap name if never deployed to in x time period.

Some things have improved over the year I have been using Snapcraft, but the rate of progress is not confidence inspiring.

Key points:

  1. Encourage and create an environment for better reviews.
  2. Better and easier deployment system for publishers.
  3. Better bug reporting system where issues with the sandbox don’t go ignored for over a year.
  4. Allow support to connect to any git system not just GitHub.

Admit when Snapcraft is doing something bigger than it is able to actually support or maintain in a satisfactory manner and cut it or manage it on a proper scale for what Snapcraft can support.

The Sandbox should be optional and not just for Publishers, for users too, I should be able to disable the Sandbox and even build a project locally if I desire via the Snapcraft storefront. Publishers should be able to list “insecure” apps, and there should be some check mark system to show which apps support the Sandbox and which do not; including search filters. Snapcraft already supports plenty of what I assume to be legacy snaps listed as “Potentially Unsafe Proprietary Code”.

And there should be a proper ticket based request and review system, not this madness at the moment where people have to request permissions on the forum.

1 Like
2

here comes a workaround to one of your pain points… as far as i understand it; one idea: maybe you could describe your set up/what you are actually doing?

i guess you hooked up the launchpad builder to a github project, is that correct? as far as i am aware that trigger has basically no configuration, so it kicks of a build and publish to edge channel for each commit to the master branch (maybe it is not the master branch but the default branch dunno). as there is no configuration you have to do anything fancy externally.

anyway, the way we use it: we want weekly test builds, so i have a fork of our project connected to the launchpad builder. Once per week we push the weekly revision to the master branch there. launchpad picks that change up and builds and publishes to edge. the published version gets tested and if green it gets promoted/published to the beta channel.

3

You are correct, I have connected the launchpad builder to a GitHub project, but also that is the only option the website interface gives me.

The separation of the Launchpad builder git to a development fork is a good idea to deal with this, but the problem is most people are more likely to just connect directly to a git and every little change they make will trigger a rebuild which could put a lot of strain on the backend of snapcraft.

4

I like the idea of Snap. It’s just so much work to use it successfully. After many frustrating hours of building snaps with a local plugin, reading the incomplete and outdated documentation, I feel the same way. There seems to be a lack of proper software engineering. Some design choices seem to have been thrown out after a while without updating the documentation. It’s little things here and there that you have to find out using trial and error because the documentation is either ambiguous, incomplete, or simply wrong.

  • What’s the deal with V1 and V2 plugins?
  • Why does core22 not support local plugins anymore? Isn’t the idea of a versioned plugin API to maintain backwards compatibility?
  • Why are the plugins supported 7 months ago now legacy plugins? Shouldn’t they just stay where they were because of the versioned plugin API?
  • Why does a local plugin have to be defined with a different name (PluginImpl) than a supported one?
  • Why is cross-compilation such a mess? (Is --target-arch now a thing or not?)
  • Why is snapcraft --verbose documented but doesn’t actually work?
1 Like
5

These are all good considerations, I think I can comment on some of them:

The first plugin architecture (used in core18) was changed to be much simpler in core20. In Snapcraft 7 plugins were migrated to craft-parts, but they keep the same general structure of V2, with a different schema validation method.

One reason is that local plugin authors were using all sorts of Snapcraft internals instead of just the plugin API when writing local plugins, and that was causing problems because it made internal refactoring impossible. But you can still use local plugins if you build for earlier base, they’re only disabled for core22.

Plugin versions are tied to bases. V1 for core18, V2 for core20, and craft-parts plugins for core22. If you use core18 as a base, V1 plugins will be available.

Cross-compilation is not supported as a feature because it’s impossible to make it work in a generic way for all situations. There is a mechanism to handle architectures and make them available to advanced grammar (using on and for), but cross-compilers must be invoked manually by the developer.

This is a CLI switch introduced in Snapcraft 7 for core22, but core20 and core18 builds are verbose by default so the option doesn’t make much difference in the output.

Update: I thought the --verbose fix for core20 and earlier was already added, but it’s still missing in Snapcraft 7.2. This is being addressed now and should be available in Snapcraft 7.3.

3 Likes
6

I agree it would be nice to unregister a registered snap name. A problem I have run into is I would have to attempt to register a snap to know if it was already registered. If it wasn’t registered, then it would register it without a way to unreserve it. So a way to search for registered snaps before registering them would be nice.

Are you describing classic confinement?

If a snap supports confinement, then you get all the benefits of it being confined (such as system stability), so I wouldn’t recommend disabling it (even if you could).

Would your competitor to snapcraft involve hiring dedicated reviewers to supplement the missing peer reviewers from not posting to the forum? I like the idea of using the forum because it builds a process of transparency and community.

I see a lot posted in the snapcraft blog/forum about collaboration and engagement through “Snapcrafters”. Not to mention kde’s support, feedback about the steam snap, etc. What do you suggest for improving reviews and engagement?

What git providers do you think should be supported? Are you aware of any git providers that already do work but are undocumented? Are you aware of any technology/way to manage the differences between build pipelines and apis between build providers?

7

Hey Picchietti

You know, my comments about the Sandbox can be disregarded, I see how important the sandbox is now and having experienced Debian packages, Arch AUR, and Flatpak since, it is overwhelmingly obvious how much better Snapcraft is, and how much easier it is to deploy software on Snapcraft and this probably can be mostly attributed to it’s Sandbox system. Anyone can submit software on Snapcraft using the Web/Account panel and have it displayed in the software center within minutes without manual review, I can’t say I know of any other deployment system like this on Linux.

It may seem I have been harsh on Snapcraft, but to be fair, having been the only packaging system I had experienced at the time of writing the original post you could also say, that I’m now being too soft on it because I’m now comparing it against much lesser systems in the ecosystem.

I won’t start a competitor just yet lol, but I do think some functional improvements could be made to improve the user engagement side. (although my inexperienced opinion would be that source code scanning to generate trust ratings based on detected obfuscated code or potentially malicious function calls etc could alleviate some of the duty of the Sandbox, although that is an entire beast of its own and with so many programming languages, well, no small feat, but maybe some AI solution could yet alleviate that too which is plausible, known malicious repositories and known non-malicious repositories and known insecure releases of repositories could be trained against some transformer model)

I don’t think anyone needs to be hired, particularly reviewers, I just believe the right environment needs to be fostered to attract and platform them.

I agree with your view that the forum is building a community to an extent but it’s a engine room scenario, it’s not something you want as a facade to the operation. Reviewers and things like that, they need a professional front to maintain, like a facebook business page or medium account, more of an outlet.

So what I think could achieve this is:

  1. Have a special system for Critic reviews, so verified critics can have their reviews more visible than standard user reviews. (to become a verified critic you just need to register a critic account option, which is separate to a standard user account, and critics could get vouches that increase their reputation and credibility putting them above other critics reviews on software)
  2. All reviews are tagged to the specific software release version, so that any bad reviews taint newer versions of the software release less badly.
  3. Users need to be able to filter reviews in some basic manner, for example hiding any reviews not for the latest or selected release version.
  4. Software publishers should have the ability to demote the priority of critic reviews on their software page if that review is for an older release of the software, they should also be able to respond to these reviews with the same level of visibility on the main page.
  5. Critics should have profile pages, like a software page, that they can customise and lists all of their reviews. Critics should be able to sort them and present whatever reviews they preference in some top view of the page, so maybe a selection of that Critics favorite software releases or similar, like having playlists on YouTube, software Critics on snapcraft should have playlist they can create of different software they have reviewed and of their reviews of that software.
  6. Users could have customised review feeds per software page, for example, a user could like Critic reviews and based on the users likes that user could be shown the reviews of the Critics he prefers first over other Critic reviewers - where possible, if no liked critics have reviewed the software the user is looking at it would fall back to just the simple highest Critic rating / like count first.

That would be a good start, because it gives the Critics some sense of value for the job they are doing for free, no one will do it for free unless you make it feel like they are getting some personal value back from it. For example, mostly, people submit software on Snapcraft for free because they get that value back from the exposure Snapcraft brings to that software and the quality of their web and native software center distribution system. If this was the same level of value back for people posting reviews, then people would just post them for free to establish their foothold as a spokes person of software, a reviewer of taste, to strengthen their general presence in the field online, maybe even to improve their search engine appearance for their name as a journalist/reviewer/blogger or sorts. People want value back, and you can give reviewers that, in those ways and more. People will post reviews and good ones on Snapcraft if they get that value back and Snapcraft can easily give them value like search engine exposure, help establish their presence online, with the right additions discussed above.

Platform reviewers with the same level of quality as you platform the software publishers. Reviewers are so important to establish a community because opinions start conversation, opinions bring attention, and bringing potentially already well established internet journalists to the platform can also help strengthen the SEO of individual software release pages on Snapcraft.

As the software library grows on Snapcraft, so will the obscurity increase as many search terms and options in genres become saturated, hidden gems will become over looked, lost in clutter. BUT. What if you find a piece of software you are interested in and you see the most visible top rated review for that software is by a well established Critic on the platform called “Bandicoot” and you absolutely agree with everything or most of what Bandicoot had to say about that software after trying it out, and you think, wow, Bandicoot has good taste, maybe I will go to his Critic profile page and see what other software he has reviewed on Snapcraft because if he liked it, I probably will too, because we seem to have similar taste.

Suddenly that problem of software becoming lost, hidden in saturation, is massively alleviated, suddenly you have this whole new system of bringing attention to other pieces of software that could otherwise have been totally over looked hidden gems to some people, that where just lost in a sea of snaps.

The value of platforming critics along with software is so invaluable, it’s the spice that Snapcraft is missing to really become the king of software distribution.

With Git support, notabug for example would be nice to support, obviously I know nothing about the technical implications of supporting other Git providers on the back end but supporting any of the other mainstream Git providers would be nice, as an option, for those who want it, because not everyone wants to be forced to use GitHub, many people are quite avidly against GitHub, which I know is absurd, I am a big fan of GitHub myself, but I can also respect the arguments people make against using GitHub and why some of these other providers provide a service which they feel is better for them or their project. It’s not vital as anyone can just fork to GitHub if they really want their software on Snapcraft, but it’s also not always that simple, one example would be that GitHub has a 100mb file size limit, although it may be rare, some projects may need to make adjustments to fit some of their larger files onto GitHub. Just one example of how GitHub can be a limiting factor and not just a preference.

1 Like