Top-level package names, UX questions

[Mark Shuttleworth]

On 16/03/15 11:22, Gustavo Niemeyer wrote:
> Whatever scheme we choose, at the end people should be able to pick an
> identifier without being concerned about future unintended conflicts.

Strongly agreed.

Say I decide to make a package called "wizard". I can publish that right
now as "sabdfl's package of wizard" and do that without asking anybody's
permission. We should preserve that.

If Frank hears about my package, he would have to say "please install
the sabdfl wizard package", not just "the wizard package", because
"wizard" is not yet a mainline package (and we need a better term for
what I'm calling mainline in this case). So Frank's system knows that
he's got the "wizard" package from sabdfl, not any other wizard package.

Say now that there is an official, mainline package "wizard" published.

I don't think Frank's package magically changes to the new one, because
his system explicitly had the sabdfl one installed. As far as Frank is
concerned, there is no change at all. In fact as far as any user of the
sabdfl wizard package is concerned, nothing changed at all. They COULD
now ask for "the wizard package" on another system, and they would get
the official, mainline one. But if they asked for "sabdfl's wizard
package" on that other system, they'd get the same one that Frank is using.

The main question is whether we want Frank to have to think about things
if he decides to ADD the official, mainline wizard package to a system
which already has "sabdfl's wizard" installed.

If he refers to the sabdfl wizard package as "wizard.sabdfl" every day,
then he can add "wizard" and not change anything, because "wizard" and
"wizard.sabdfl" are different. But that means dealing with a lot of
quite awkward names.

If we say that the sabdfl wizard package is just "wizard" for the
purposes of any local commands, then:

 * there is no issue until Frank decides he wants "fred's version of
wizard" or the "mainline version of wizard"
 * if that happens, he has to choose which one he wants
 * if he replaces one with another, then his scripts etc might now do
something different

.. but on the whole, I think it's good to socialise convergence of
packages in a namespace. I think it's GOOD to allow developers to
bifurcate code, but to encourage them to converge on the user experience
of that code. And I think "package.command" is much more user friendly
than "package.developer.command", which is worth some other dissonance.

So I think I would be +1 on:

 * anybody can use any name for a package
 * some packages are "mainline" or "official" and can be installed just
by package name ("wizard")
 * developer packages are installed with explicit reference to the
developer account ("sabdfl's wizard")
 * commands are always "package.command" unless they are frameworks
 * the existence of a mainline package doesn't mean developer packages
are replaced automatically (no unexpected consequences)
 * users must choose which version of a package they want, either
mainline or developer
 * sometimes, developers will need to coordinate with one another or
with canonical

We do have a mechanism to rename installed packages, which we hope not
to use often but it is possible, at least.

At this stage, I'll rest my wizard :)

Mark