[Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

On 4/24/2012 11:44 PM, wren ng thornton wrote:
> To pick another similar namespacing issue, consider the problem of 
> Google Code. In Google Code there's a single namespace for projects, 
> and the Google team spends a lot of effort on maintaining that 
> namespace and resolving conflicts. (I know folks who've worked in the 
> lab next door to that team. So, yes, they do spend a lot of work on 
> it.) Whereas if you consider BitBucket or GitHub, each user is given a 
> separate project namespace, and therefore the only thing that has to 
> be maintained is the user namespace--- which has to be done anyways in 
> order to deal with logins. The model of Google Code, SourceForge, and 
> Java all assume that projects and repositories are scarce resources. 
> Back in the day that may have been true (or may not), but today it is 
> clearly false. Repos are cheap and everyone has a dozen side projects.

Actually, I like the idea of combining an assigned User name with the 
repo name as the namespace. We already have login names for haskell.org, 
why not use those. I agree that it is not an end all, but it would be a 
start. My top level namespace would be Org.Haskell.Glebovitz. It is 
democratic and it identifies the code by the repoand the user the 
created it. If someone else decided to use their github id then it their 
modules would be org.github.username or org.github.project. Of course 
people can choose to ignore the namespace common practice, but they can 
do that anyway.

>
> If you look at the case of Perl and CPAN, there's the same old story: 
> universal authority. Contrary to Java, CPAN does very much actively 
> police (or rather, vett) the namespace. However, this extreme level of 
> policing requires a great deal of work and serves to drive away a 
> great many developers from publishing their code on CPAN.
>
> I'm not as familiar with the innards of how various Linux distros 
> manage things, but they're also tasked with the additional burden of 
> needing to pull in stuff from places like CPAN, Hackage, etc. Because 
> of that, their namespace situation seems quite different from that of 
> Hackage or CPAN on their own. I do know that Debian at least (and 
> presumably the others as well) devote a great deal of manpower to all 
> this.

Yes, but that goes back to my comments about upstream and downstream. 
Hackage can try to solve the problem for itself, but eventually someone 
is going to put together a distribution, whether it be ubuntu, or 
Microsoft and they will have to sort out the name collisions for their 
packages and modules. If we have a good naming scheme to start with, it 
will make the downstream problem a bit easier. Even so, they will 
probably change it anyways. I know that ubuntu and fedora take different 
approaches to packaging. When I try to use a package like Qt on these 
different platforms, I have to figure out which package contains which 
library.

>
> So we have (1) the Java model where there are rules that noone 
> follows; (2) the Google Code, CPAN, and Linux distro model of devoting 
> a great deal of community resources to maintaining the rules; and (3) 
> the BitBucket, GitHub, Hackage model of having few institutionalized 
> rules and leaving it to social factors. The first option buys us 
> nothing over the last, excepting a false sense of security and the 
> ability to alienate private open-source developers.
>
>
I think my combo of formalized namespace and social rules would work 
best here.  The problem is that we do have module collisions because the 
namespace is too simple. Right now it is not an issue because the 
community is not huge. Eventually it will be a problem if Haskell 
popularity grows.

> There is no technical solution to this problem, at least not any used 
> by the communities you cite. The only solutions on offer require a 
> great deal of human effort, which is always a 
> social/political/economic matter. The only technical avenues I see are 
> ways of making the problem less problematic, such as GitHub and 
> BitBucket distinguishing the user namespace from each user's project 
> namespace, such as the -XPackageImports extension (which is 
> essentially the same as GitHub/BitBucket), or such as various ideas 
> about using tree-grafting to rearrange the module namespace on a 
> per-project basis thereby allowing clients to resolve the conflicts 
> rather than requiring a global solution. I'm quite interested in that 
> last one, though I don't have any time for it in the foreseeable future.
>
There probably is a technical solution, but no one is going to discover 
it and build it anytime soon. dI think we all agree that a centralized 
global solution is out. No one would want to manage it. I do think the 
repo.username namespace has potential. The problem is that informal 
social convention works if the community is small. Once it starts to 
grow it has to be codified to some degree.