On Mon, Mar 16, 2015 at 7:31 PM, Mark Shuttleworth <[email protected]> wrote: > > * you can only install one foo at a time (choose foo.beuno or foo.jamie) > * you must use it as foo.command
After talking to Alexander for a bit, I still feel this is the best trade off for the command line experience but broadening the view a bit to the phone and desktop, there's something worth thinking about as well. In the command line, the commands are the UI. This works great, feels snappy. However, in a GUI (webdm, touch, future desktop), you install apps by looking at titles, descriptions and icons. You will be, unless we make some changes, unaware of what an app's package name is. You don't care on GUIs where you see icons and names what a package's name is, you click on icons and titles. The proposal we have on the table pushes an awkward interaction there, where all GUIs will need to be aware of the fact that the same package name can be provided by many developers and you can only run one at a time. You'll essentially see 3 "calculator" apps, but 2 of them will have the same package name when a third doesn't. The result of installing one or the other, which all look alike, will be different (one will be co-runnable, the other will want to replace your current one). On the desktop it'll be even more awkward, as sometimes you'll use the command line, sometimes you'll install from the scope. I think if we felt this was the right path to go down, even in GUI scenarios, we could think about how to make sure developers understand that when they pick a package name, they are potentially becoming an alternative to an existing set of apps. I fear it might make things harder down the line for us, as we might end up with a dozen apps that are called "evolution", none of which we feel is the correct use of that package name, and we have to rename a dozen existing applications with a user base. I can think of 2 paths to follow: 1) Circle back to unique package names, drop developer extensions for them and have people create their own forks with a different package name "apache_beuno". 2) Allow running apps both by package name "apache.command" or full package name "apache.beuno.command", the latter used by GUIs and the former by humans from a command line 1 feels cleaner from top to bottom, but it puts a bit too much emphasis on picking the right name from the beginning, going back to Gustavo's comment on "people should be able to pick an identifier without being concerned about future unintended conflicts". 2 I think addresses both sets of UIs, at the expense of a difference in behaviour if you switch from the GUI to the command line. There might be more options, I'd love to hear them! -- Martin -- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
