DIP11: Automatic downloading of libraries

[Jacob Carlborg]

On 2011-06-19 19:15, 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)

I completely agree. I key feature for why I chose Ruby is because it 
allows you to call a method with out parentheses, don't know about the 
other above mentioned languages.

> 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...

Yes, that would be a big problem. But, the advantage we have is that we 
can change the language when developing the tool, if necessary. I mean 
before we get any more packages than just test packages.

-- 
/Jacob Carlborg