The DUB package manager

[Sönke Ludwig]

Am 18.02.2013 00:51, schrieb David Nadlinger:
> On Sunday, 17 February 2013 at 14:40:26 UTC, Dicebot wrote:
>> Packaging is best done (and should be) by OS package manager, not
>> hundreds of languages-specific managers. Good language package manager
>> in my opinion is just an information source for OS package builders.
> 
> D does not lend itself well to OS-level packaging, because different
> compilers as well as different versions of the same compiler will not be
> binary-compatible in the foreseeable future.
> 
> I think any D package management tool needs to be able to handle
> multiple coexisting compiler configurations, or at least allow being
> used for multiple installation (similar to RubyGems and rbenv/rvm).
> 
> David
> 

On top of that, there are also certain use cases which usually are not
possible using the typical OS package managers:

 - Install different versions of the same library for different
applications (in theory the right version schema would solve that, but
in practice this goes only for mature/stable libraries)

 - Installation by unprivileged users

 - Working on a library and a dependent application at the same time
(DUB supports "local" package sources for that) - normally this would
require to upload a new version of the library after each change and
then reinstall, or to completely leave the package system and manually
set different import paths for development

 - Automatic dependency installation not just for published packages,
but also for local/closed/WIP ones


Then there are also a lot of other D specific things to consider, such
as compiler flags/version identifiers that may be defined in a single
package, but need to be applied throughout all dependencies and the
application itself to not get compiler/linker errors in the end.

But on the other hand, adding support for automatic OS package
generation may be a good option. All necessary information would be there.