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
