Stop untracked dependencies!

[Malcolm Wallace]

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

> * We Need Free Packaging
> 
> Anyone should be able to create a package at any time for use in their 
> projects without having having to negotiate with any particular 
> centralized authority or community.

Agree.  And this is the default current case.

> HTTP URLs have this property.  The current package namespace does not.
> Malcolm says "think wiki."  I say: think world wide web.

Wiki might have been a poor example, but I did also mention DNS as
a model for package naming.  URLs are *not* completely arbitrary.
You first require a valid domain name, which gets allocated by a single
(but distributed) authority, using a lax first-come-first-served policy
(at least approximately).  And then you can only create a valid URL
if you have permission from the domain owner to write to the webserver.

You want all package authors to distribute their works through
individual webservers, where they have their own self-appointed
authority.  I don't have a problem with that, but I would also like
to have one or more trusted webservers, which collect together many
packages, making them all available easily, with search facilities,
and some reasonable dependency/update policy.  The "trusted" authority
would be, broadly speaking, the (or /a/) community, which would
probably strive for a certain coherency and even perhaps "style"
across packages.

Think of the difference between building a Linux system by collecting
the latest versions of every system tool and application yourself from
the individual project websites, resolving all cross dependencies
manually, or just downloading a complete RedHat, debian, SuSe,
whatever, distribution, where somebody has already done the dependency
analysis for you.  Debian is a particularly good example, since you
might collect only a minimal system to start with, but be secure in
the knowledge that when you want to add more packages, they will be
compatible, and the community has resolved all of the dependencies
for you transparently.

Some people will want to do the former.  More power to them.  But the
vast majority will prefer the latter, simply for convenience.

> * Free Packaging Means We To Handle Collisions in Module Namespace
> 
>                           I am totally ok with each module name 
> mapping to one and only one implementation per program.  I just want 
> to be able choose that implementation even when my program uses two 
> packages that both happen to export the same module name.

Yes, clashes of module names is absolutely the most central issue in
the whole library universe.

In the beginning, the Haskell module namespace was flat - big
opportunity for overlaps - bad.  Then we introduced hierarchy - a much
larger namespace, more easily searchable - but still the potential
for overlaps.  So then we introduced "packages" - to gather modules
together, so that we could permit the same hierarchical module name
in different packages, provided the package name was different.
Originally, we said that package names must be unique, but now you
want package names to overlap as well.  So now, to avoid ambiguity,
the proposal is that the *storage location* of the package should
be unique.

It seems to me that we are just pushing the overlap-resolution problem
around the plate - each time a new namespace is introduced, the
potential for overlaps rears its ugly head again, and yet another new
mechanism is proposed, which eventually fails to solve the problem too.

You are against a central authority for allocating package names,
yet you seem happy to accept a central authority for allocating the
domain name part of a URL.  So I conclude that you are not against
central authority itself, but rather you would prefer to use a
"standard" well-established authority (the DNS) rather than a new,
yet-to-be-implemented authority (Hackage).  Would that be a fair guess?

> * We Need to Associate Module Names with Specific Packages
> 
> In associating module names with particular packages, the design 
> choices come down to:
> 
>    a. using a "Modules" file that maps module names to package ids/URLs
> 
>    b. allowing package ids/URLs in import statements
> 
>    c. allowing package *names* in import statement and using an
>       external "Packages" file to map package
>       names to package ids/URLs.

There is another choice:

     d. Have one or more external servers resolve module names to
        specific packages.  Requires a single file specifying a list of
        servers to contact, in preference order.  If a server cannot
        resolve the name, it is delegated further down the list.

For a project that uses lots of wild packages with odd version numbers
and weird dependencies, you might need to set up your own dedicated
server just for that project.

But most projects would just use two servers: (a) a local one
for locally-written packages, and (b) a central community one for
publically-contributed packages.

Regards,
    Malcolm