a cabal for D ?

[Bruno Medeiros]

Hi Russel. (BTW, I was the guy a few weeks ago at the London Java 
Community Meetup pub meet that Barry Cranford mentioned in an SMS. Sorry 
you couldn't make it, maybe next time. :p )

On 18/03/2011 08:52, Russel Winder wrote:
>
> Note that every language-specific package manager conflicts directly
> with every operating system package manager.  Thus RubyGems, CPAN,
> Cabal, Maven, Go, etc. conflicts with the package management of Debian,
> Fedora, SUSE, FreeBSD, MacPorts, etc.

Which is the way it should be. (Note that "conflicts" is likely not the 
best word, rather "ignores" or "does not make use or interact with" is a 
better term.) I'm well convinced of this because these two - OS and 
language package manager - /usually/ serve very distinct purposes. The 
OS PMs are usually focused on installing applications, not building them 
(yes, there are exceptions, like Gentoo). In particular the OS PMs most 
likely won't support functionality you would want from a language PM. 
(say for example that you would want to specify that your library has a 
dependency on any other library that exports a D package named org.foo.bar?)
But we don't even need to go there, just the fact that OS PMs are not 
cross-platform is reason enough for them to be unsuitable to be used (on 
their own) as language PM. There needs to be a language PM abstracted 
from OS/platform.
Perhaps some additional (and optional) integration with the OS PM could 
be available in the language PM. But the language PM would still be "on 
top". And even so I'm not convinced this integrations makes much sense. 
Maybe for dynamic and interpreted languages like Ruby and Python, where 
built application and sources are often the same... here perhaps the 
term "conflict" as mentioned above is more appropriate, the distinction 
between end-user and developer-user is less clear. But none of this 
applies to D, being a compiled language.

-- 
Bruno Medeiros - Software Engineer