On 2011-06-19 19:37, Lutger Blijdestijn wrote:
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.
That's true. It would be possible to write extensions in D even when the
config language is Ruby, although it would be more complicated.
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.
I don't think it's worth it. It also depends on how much the complexity
increases.
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.
I'm always open to suggestions.
--
/Jacob Carlborg
