Top-level package names, UX questions

[Natalia]

Hello!

As per our conversation today in the snappy stand up, I'm restarting
conversations for this thread.

We have some work already available in the store where a top level
namespace can be set via admin for a package and then that package is
accessible in the index via the full package name or the top level
namespace, but we need definitions for the UX for the developer.

I'm currently blocked on this to continue with this task. Working
other tasks china-related and improving index search capabilities to
include package name and top level namespace.

Thanks!

On Wed, Feb 25, 2015 at 11:57 AM, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> On Wed, Feb 25, 2015 at 9:23 AM, Alexander Sack <asac at canonical.com> wrote:
>> On Tue, Feb 24, 2015 at 4:02 PM, Gustavo Niemeyer
>> <gustavo.niemeyer at canonical.com> wrote:
>>> With juju we used an alias to the fully defined namespace, and it
>>> works pretty well.
>>>
>>> As a side note, the convention of <package name>.<user> feels somewhat
>>> unfortunate. I'm not sure if there's still time to tweak it or if you
>>> are married with the concept to a deep level already. If possible, I
>>> would try to design a convention that is slightly harder to obtain
>>> ambiguous interpretation from. As example based on the few mentions in
>>> your text, consider the effect of having a user named "start".
>>
>> We are not married to the current syntax/scheme, but we didn't come up
>> with something better. Any ideas?
>
> I would look for a convention that more clearly separates the
> components unambiguously. You have control of the allowed syntax on
> package names, and can also define what the convention for extensions
> is, so it should be easy to avoid the situation described above. Note
> that if you namespace the package itself, it may not be necessary to
> namespace everything inside it (if it's user/package, then it's okay
> to have user/package/foo).
>
> Rather than trying to come up with a single proposal here, I'd rather
> keep these ideas in mind.  If they make sense, let's meet to
> brainstorm on options.
>
>
> gustavo @ http://niemeyer.net
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel