[ccan] Moving modules to vanity naming?

[Adam Kennedy]

The best approach to this kind of thing is not to pick a structure
that you like, or think in terms of categorisation for it's own sake.

Consider the machine-automated result that you want to achieve.

For example, Perl has a single unified namespace and a large volume of
modules where code where maintainership needs to move from person to
person over time.

As a result, while we may store the packages in author directories,
the permissions database controls which author's package is the
"legitimate" one-true-package for module name foo. This knowledge is
compiled into an index, so that when module foo declares it has a
dependency on module bar, we know which author's version of bar to
actually depend on.

In your case, what precisely are you depending on, and how will things
be maintained over time?

If module foo declares dependency on bar, will it be declaring
specifically on rusty/bar (no pun intended) or is that dependency on
"the most recent authorised release of bar". If the latter, and
dependencies are declared in terms of rusty/bar, then ever time you
change the maintainer of bar, you'll need to cascade out to everything
that consumes it and change all of THOSE as well, which may means
changing all THEIR stuff, and so on recursively.

Always design your repo for actual real (and automatable) effects, not
for design sake. And think all the effects through to their logical
conclusion, failure modes, etc.

Almost every time we've done arbitrary design stuff in the past, it's
been a disaster.

No one consideration (easy to do git permissions) should ever dominate.

Adam K

On 3 November 2010 13:28, Rusty Russell <rusty at rustcorp.com.au> wrote:
> On Wed, 3 Nov 2010 12:32:57 pm Alexander 'hatred' Drozdoff wrote:
>> In this case, I think, more good put 'author' first - with this simple 'ls' group author's
>> packages :-)
>
> I think that group-by-name is what David wanted to avoid, but I don't really
> mind.
>
>> Also, is it possible to add 'tags' functionality to CCAN? Add some new field to manifest file
>> (_info), like:
>>   Tags: memory, image processing, crypto
>>
>> And use this for navigation on site. This can solve trouble with navigation via modules with same
>> (or in one subject areas) functionality. Use this only for navigation on site.
>
> Certainly, and there's nothing stopping people starting that now.  But maybe
> we're better off just writing clear descriptions and letting Google sort it
> out?  We already extract that for the module web page...
>
> Cheers,
> Rusty.
> _______________________________________________
> ccan mailing list
> ccan at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/ccan
>