DIP11: Automatic downloading of libraries

[Jacob Carlborg]

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