Johannes Pfau wrote: > Lutger Blijdestijn wrote: >>Jacob Carlborg wrote: >> >>> On 2011-06-14 15:53, Andrei Alexandrescu wrote: >>>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11 >>>> >>>> Destroy. >>>> >>>> >>>> Andrei >>> >>> Instead of complaining about others ideas (I'll probably do that as >>> well :) ), here's my idea: >>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D >>> >>> I'm working on both of the tools mentioned in the above link. The >>> ideas for the package manager are heavily based on Rubygems. >>> >> >>Looks good, and has a cool name too! I love the reference to the >>mars / phobos theme. >> >>After 'cloning into orbit...', I think I'm missing a ruby ffi binding. >>Is it possible to build it already? Or is it too early for that? >> >>If I'm not mistaken the dependency on ruby is nicely factored into a >>very small part of orbit and could easily be replaced if someone would >>be inclined to do so. I'd prefer this over ruby, but I prefer ruby >>over the dsss format. In the end, what matters is the value of the >>tool. > > I personally think that ruby is a good choice for the config format > (lua, python, whatever would be fine too), as we definitely need a > programming language for advanced use cases (debian uses makefiles, > which are a pita, but together with bash and external tools they still > count as a programming language) > > It should be noted though that replacing the config syntax later on will > be difficult: even if it's factored out nicely in the code, we > could have thousands of d packages using the old format. In order not > to break those, we'd have to deprecate the old format, but still leave > it available for some time, which leads to more dependencies and > problems... >
For D programmers that need this kind of advanced functionality it means they have to learn ruby as well. Whereas it's pretty safe to assume they already know D :) Another advantage of D is that built related scripts and extensions can be distributed easily with orbit itself. I'm thinking that maybe it is possible for dakefile.rb and dakefile.d to coexist in the same tool? I'm not sure if that creates problems, or if such extra complexity is worth it. However, those that really want to use D could try to convince Jacob Carlborg that D is a good alternative by implementing it, if he is open to that.
