On Wednesday, 2 January 2013 at 21:02:51 UTC, Nathan M. Swan
wrote:
Here's my proposal for a D Package Manager. I want to make sure
it has a good design before I write any code, so here it is:
http://wiki.dlang.org/User:Nathan_M._Swan/DPM_Proposal
Sorry for being a bit blunt, but: What advantages would this
provide over just using the package management facilities of
one's favorite distro? Keep in mind: http://xkcd.com/927/ ;)
The biggest problem one faces when trying to package D libraries
right now is that the different D compilers (DMD, GDC, LDC), but
also multiple versions of the _same_ compiler, are not binary
compatible to each other. So, if you don't want to use a build
tool like rdmd to build *everything* from scratch each time, you
need to manage multiple binaries around for any given library,
one for each compiler version.
As it is actually quite common to have multiple D compiler
versions installed side-by-side – e.g. DMD for fast iteration and
GDC/LDC for release builds, or transitioning one's projects one
by one to a new DMD version after the release – I think that any
design which doesn't address this issue isn't worth the effort
over just using an existing solution.
It might be a good idea to have an extensive look at the popular
package management systems of other languages like Ruby and Node
the issue, particularly the ability to easily "freeze" an
environment for deployment (see npm, bundler). The way Ruby
(resp. rvm/rbenv) handle the binary compatibility issue, though,
always seemed a bit backwards to me, which is probably a result
of needing to retrofit the feature over an already popular
package manager.
David
