Namespacing snaps

1

I notice every once in awhile there’s a post regarding someone needing to rename a snap, claim a snap name that someone else took, etc.

With package managers like Apt and Brew, there’s a single package name. On GitHub and Docker Hub, repositories are namespaced under an org or username. No, they aren’t package managers but I like the approach.

This aids in preventing package name collisions and makes the whole ecosystem more collaborative. Let’s face it, sometime people create apps with the same name, not always with the same purpose. Outside of large commercial apps wanting to enforce trademark, I think namespacing would benefit many users.

Thoughts?

1 Like
2

In the early days we actually had exactly that: every snap was namespaced after the developers account name. This created a number of issues:

  1. Now you need to also qualify locally what you have installed. In other words, the conflict happens on your machine instead of the store.

  2. It made it harder for people to find what they want. Whose copy to take when there are 10 different copies and you don’t know better.

  3. The trust model gets more complex, because trust is really associated with a publisher and not with the software itself.

  4. The refresh process becomes non-intuitive. Updates across publishers will often not work, even if the software is the same and the name is the same.

  5. Lastly, it doesn’t improve the situation much. If you want to namespace your snap, you can trivially do so right now. Just prefix it with your developer account name, which is a convention multiple people use.

So, the conversations around conflicts that we observe here in the forum are actually a good thing. They are mainly addressing the first and second issues. We could ignore them, but it sounds like a service worth providing for improving the ecosystem and the user experience.

3

For what it’s worth, this is more or less why namespacing never really made it into package management either. There have been some attempts to introduce some level of namespacing at the resolver level (SUSE’s “sticky vendors” for example), but at the end of the day, namespacing adds more complexity for very little gain.

Don’t get me wrong, it’s very useful at the runtime level (IPC, etc.), but it does add a substantial amount of overhead to figure out what’s going on…

4

I believe the namespace will be needed as number of packages increases.

Look at a real example of npm.
At the beginning It used the one global namespace, and later introduced the scoped package.
https://docs.npmjs.com/getting-started/scoped-packages

As for snapcraft now, when I try to register “firefox” snap, I got the following message.

The name ‘firefox’ is already taken.
Here’s what you can do:

Choose an alternative name that people can associate with you, for example ‘hnakamur-firefox’.
File a dispute to request the existing snap be renamed.

I think this convention is not so good way because of the following two reasons.

  1. If your snap username is something that seems like a package name, it becomes confusing. For example, if your snap username is “firefox”, then the suggested snap package name becomes “firefox-firefox”.

  2. You cannot reserve snap package names starting with your snap name like “username-*” beforehand. Someone might create packages with prefix of your username.

the conflict happens on your machine instead of the store.

I believe this is the very reason why we need namespace.
Snap files are located at /snap/, so we need to choose name which does not conflict to other snap packages.
If you use only the registered snaps, the conversations around conflicts works fine.
However, if you want to use unregistered private snaps as well as the registered snaps, you cannot rely conversations to address conflicts.
We need the naming scheme for avoiding conflicts without the conversations.

So how about adding the user namespace as well as the global namespace?
To minimize the change, I think of two options on the naming scheme.

  1. Prefix snap name with username followed by double hyphens. For example, username–snap-name. The modification needed is denying two consecutive hyphens in snap names, and ask users to change snap names if they have two consecutive hyphens.

  2. Prefix snap name with hyphen, username, and hyphen (like css vendor prefix). For example, -username-snap-name. The modification needed is allowing a hyphen at start.

In both ways, the validation is needed so that only prefix of your username is allowed.

These package name lives alongside the global packages like snap-name nicely.

I’m new to snap and it seems a nice packaging method which overcome the problems of the existing packaging like deb or rpm.
I think it is crucial to have reserved namespaces for a user so that snap will be successful with a massive packages.

1 Like
5

That’s actually what we have today. There are no conflicts since you need to have the name reserved before you can publish under it.

So firefox-firefox is confusing but firefox--firefox is fine? :slight_smile:

The current convention allows you to use neither, and go with firefox-tweaked or hopefully something that makes more sense given which actual changes were applied on it.

6

No but felicianotech/firefox and mozilla/firefox would be nice.

7

Unfortunately that doesn’t work, as the end result is exactly the same as allowing everybody to release a snap named “firefox”, which means:

  1. Everybody is stumbling upon everybody else all the time, potentially with completely unrelated pieces of software
  2. It also means the potential to steal data by naming something that looks the same but is not, yet has access to the same data
  3. The fact a piece of software is the same does not mean its data is compatible, so even if we ignore points 1 and 2, it would still be pretty messy

The scheme we have allows you to have “felicianotech-firefox”, though, and mozilla to own the “firefox” snap itself. Everybody wins.

The simplistic appearance of the current scheme gives an impression that it was put in place in a careless way, but trust me, some people actually thought about it. :slight_smile:

1 Like
8

I disagree. The org/name setup works very well for GitHub, Gitlab, Docker Hub, and more. The single flat package name is one of the reasons why the npm/RubyGem world is having trouble and why I think PPAs raised in popularity in the Debian/Ubuntu world. Obviously, not the only reason for PPAs, newer software is likely the biggest motivator and snaps do solve that.

Is that true? Is that documented somewhere? I thought I saw it was reversed, something like firefox-felicianotech. If it’s not documented, let me know where and I can add it. I think if that’s the naming scheme were gonna have to use, we should have it written down somewhere.

9

None of these install binaries in your $PATH, so the fact there are Sixty Thousand Forks of Tensorflow is not a problem at all. But once we need to decide what happens when one runs “firefox”, the problem changes. The $PATH namespace is flat, and that’s the namespace we are digging into when we accept a registration for a snap.

It is not documented because it is not special. The reason why you can register “foozer-blaster” is the same reason why you can register “felicianotech-firefox”.

1 Like