[ccan] Moving modules to vanity naming?

[Rusty Russell]

On Wed, 3 Nov 2010 02:06:53 pm Adam Kennedy wrote:
> 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.

There are several "names" here:
1) The name used for dependencies in _info.
2) The path name of the module for #include
3) The location in the distribution
4) The location in the repository
5) The prefix used by the module's public declarations.

The first four are currently the same, the last is the same without
"ccan/" in front.

Brevity matters for #5, since unlike perl it effects every usage of the
module inside a program.  The aim is to keep that short, but our current
simplistic scheme means that's going to get too crowded.  I'm
already a little concerned that I took "alloc" for what is quite an obscure
module.  I'd be happier with rusty/alloc.

#2 and #3 pretty much have to be the same: that just keeps things simple for
users.  We could split #4 from #3, but that would mean distribution would
want to be smarter than just-a-tarball, since conflicts would just get messy.

Perhaps we should just generalize things a little: any subdir which contains
an _info is a module.  This lets us create heirarchies later as needed; I
could even move that alloc/ module under the antithread/ module.

> 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.

Since I don't think CPAN's heirarchy will suit us, I'm nervous to try to
come up with any scheme for canonical names.  Using a UUID seems overkill :)

I'd rather just use symlinks when things move; effectively an alias rather
than a canonical name.

> 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.

After much pondering on this post, I think loosening the rules (and weaning
various tools off the current one-level assumption) is a better step.  Best
practices will emerge over time, I hope.

Thanks!
Rusty.