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.
