Snap does not currently have any way to easily add any external repositories. You are forced to use Canonical’s servers, which could be seen as a monopoly.
This also could scare away developers. For example, let’s say I have made an app called AwesomeApplication1 (very unique name). I decide I want to publish it, but find that Snap is a monopoly of sorts, whereas Flatpak is not. Because I want to support the thing that isn’t a monopoly, I go with Flatpak and run my own server, or publish to Flathub.
A way to fix this would be to add commands similar to:
snap repo list
snap repo add REMOTE_ADDRESS
snap repo remove REMOTE_NAME or REMOTE_ADDRESS
Furthermore, some distributions like being extremely neutral, and don’t even like it when people ask for donations before you can download (they don’t like how Ubuntu, Elementary do that). To support them, there should also be an option to disable the Canonical store. It could be like:
The argument of monopoly doesn’t make a lot of sense in this case, but let me address your actual concern which I think is Canonical having control over the repository that snapd talks to by default and not having support for easily adding other repositories.
The reason why we’ve done that is user experience. As I’m sure you have noticed, while you and me have this discussion a significant part of world is moving over to different platforms of software deployment in other operating systems, and these platforms focus not on how many servers on the internet can host another APT repository, but on how the user feels when installing software on their system.
So our attention over the past few years has been put not on how software developers can choose to host their packages elsewhere and convince users to run the right sequence of commands and dialogs to enable it, and then open several other edge cases that need to be accounted for. Instead, our attention has been put on making sure that software developers have a fantastic path to offer software to normal people that want to get things working, and give these people a great experience as well.
I honestly can understand how you would like things to be different, and my software development life is filled with personal frustration coming from being unable to make everyone happy, but I’ve also learned the hard way that projects that focus too much on making everyone happy fail because they forget the actual problem they are solving. Here we are solving the problem of having a great platform for distributing software, giving all the parties their share of control, and we’re doing that openly and inviting others that share this goal to join us. The decisions we’ve taken so far reflect that.
I understand what you mean by UX. However, it seems that the user should be allowed to install a repository if they have to. Like, people will naturally want to use Ubuntu Store if it is a good experience for users. However, developers should be able to add repositories if they like. Same for internal things. GitHub even has GitHub Enterprise, because not everyone wants to publish to GitHub (even though they have a private account).
In other words, Ubuntu Store should be default and included. However, just for even the sake of FOSS, it should be allowed to add external repositories. It might be open source, but it isn’t really free if you can’t add your own repositories easily. Like, you can work around it, but still…
A better option would even be a devmode. Like make a snap users can install that is actually called ‘snap_devmode’, which when installed unlocks adding repositories and other developer features.
Well, developers can at any time use the snap command (i assume you have looked at “snap help” (and specifically at “snap install --help”)) with the --dangerous option to install any random snap locally …
Yeah, but I also mean repositories. Real repositories. For either private company stuff, or whatever. We shouldn’t be limited to Ubuntu’s App Store only.
well, the store API is openly documented on both sides, there is even an example snap implementing it:
ogra@styx:~$ snap info snapstore-example
name: snapstore-example
summary: "Minimalist example snap store"
publisher: noise
contact: bret.barker@canonical.com
description: |
snapstore is a minimalist example of a "store" for snaps, based on the public
API specs (https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex). It
allows anyone to host their own collection of snaps for installation on
supported platforms.
See http://snapcraft.io for more information on creating and using snap
packages.
snap-id: 6Dvc1anJ89H4lOd6TeizeRigV3ubzViG
channels:
stable: 0.3 (4) 44MB -
candidate: 0.3 (4) 44MB -
beta: 0.3 (4) 44MB -
edge: 0.3 (8) 8MB -
so anyone with enough manpower could take this and implement his own snap store around it if wanted …
You can implement your own store, of course right now. The problem is that there is no way to actually add the store to user’s machines. You can’t run a store if nobody can come in.
Is that also possible to do on Ubuntu Core builds? I might be missing something, but I am having trouble finding a way to change the environment of snapd other than trying to build a custom version of the core snap.
Edit: I wanted to clarify that this is in response to the suggestion of running private snap stores.
There’s no “Ubuntu Store”. What we have is a Snap Store, which is a cross-distribution platform.
The point I’m trying to convey above is that most users don’t want to install repositories. They want to install software, and they want to have a good experience doing that. This is the focus of our design.
Don’t get me wrong, though. I know there are clearly advantages in having federated repositories, but there are also a large number of problems related to user experience that we’re not willing to just ignore. If and when we introduce such a concept, all of these will have to be nailed down beforehand, and that takes time and energy that we’re consciously choosing to put on the fundamental problems today.
Just walk around the forum for a bit and you’ll see what I mean. The volume of on going activity and work is non-trivial, and some of the topics and features discussed are extremely interesting capabilities that have a direct impact into the way users and developers interact. This is our priority.
That’s a very particular interpretation of something being free, and one you might want to rethink at some point. By the end of the day we both want to have a good platform for distributing software on, and the conversation here says more about the priorities in doing so than the nature of the work.
technically yes, practically, to gain the full feature and security set you will need a lot of manpower to implement all the surroundings from user authentication over “upload security checks of packages”, package signing, assertion management and serial-vault … the above is really only a demo, definitely nothing you want to use in production …
Okay. Snap Store, but what is the governance of the Snap Store? Does Canonical own it, able to change the rules or shut it down at any time if they like? Or is Canonical obligated to always maintain it now?
@G.S.1 Have a look at the #store topic here in the forum. That’s where the conversations about reviews, auto-connections, renames, and anything else involving the metadata maintenance takes place. It’s an open process with documents linked describing the particular exchanges on certain events, and participation on the individual events is open. In fact, participation from people with insight into related topics is very appreciated.
Obviously, this whole project is backed by Canonical, so if you are worried about its continuation, the proper way to help is to join us. Developing alternative stores for very successful projects is pretty fun.
What I meant by “repositories” is that even if the Snap Store (or a variant of it) be open source, there is no way to actually add other stores. Unless of course you were being sarcastic…
Similar to the points made above, one of the key reasons why the store is not open source is because the source code from it originated from a convoluted evolution of a system that was five (?) years old and had several strict dependencies on the shape of our infrastructure, including things that were completely unrelated to snaps. We have a team working to clean that up now, and while I agree it would be much better to do all this in the open, I pick my battles. The snapd source code which implements the complete in-system logic is entirely open, snapcraft is completely open, the tooling we use to generate Ubuntu Core is also open, the testing infrastructure we developed to test snapd is open and has multiple distributions on it, even the conversations around all of those things are open.
So, as a long term open source developer, I think we’re doing pretty well, and I’m happy that we’re sustaining our focus on solving the actual problems we came here to solve, as better detailed above.
Ok, just my 2 cents. I still think that G.S.1 has a valid point and that being able to run independent “stores” in a user-friendly fashion is important in the long run. There are various possible reasons why the current situation is not ideal, for example:
someone may want release a “controversial” app that Canonical doesn’t want to be associated with for whatever reason. Fine, but if that means being unable to release it at all through Snap, then Snap is NOT an open source platform, no matter what the licence says; or
some apps may be simply humongous, extremely resource-intensive to compile and way bigger than what Canonical’s store is willing/able to provide in terms of resources and hosting. For example, Flightgear with all its data can easily reach many gigabytes. If it’s not practical or economical for Canonical to host such packages, should this mean that they simply can’t be released through Snap?
I fully understand the reasoning behind the current design and policy, but Linux is not and should not try to be iOS with its centralised top-down ecosystem. In all snap vs. flatpak discussions the objection to the single centralised store model keeps coming back again and again and again, and IMHO Canonical should listen to the packagers’ community if it wants its platform to be successful. Frankly, adding an “add store URL” option to snapd can’t be that difficult, and no-one is expecting Canonical to somehow support these alternative stores or provide any resources or manpower to them.
That bit sounds like a reasonable suggestion, but, as ever, this being software development, could be much more difficult in practice than you’d think and not high on snappy developers’ priorities (you could try making your own PR and seeing what they make of it)…
What if you added 3 stores and now they all contain the same package “foo” (or better than that, the core package. Adding URLs is not the problem. Figuring out sane behavior / semantics is the hard part.
