DIP11: Automatic downloading of libraries

[Daniel Gibson]

Am 14.06.2011 16:49, schrieb Andrei Alexandrescu:
> On 6/14/11 9:35 AM, Daniel Gibson wrote:
>> Am 14.06.2011 16:09, schrieb Vladimir Panteleev:
>>> On Tue, 14 Jun 2011 16:53:16 +0300, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org>  wrote:
>>>
>>>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>>
>>> Why this is a bad idea:
>>> 1) It hard-codes URLs in source code. Projects often move to other
>>> code-hosting services. PHP, Python, Perl, not sure about Ruby all have a
>>> central website which stores package metadata.
>>> 2) It requires that the raw source code be available via HTTP. Not all
>>> code hosting services allow this. GitHub will redirect all HTTP requests
>>> to HTTPS.
>>
>> It should support HTTPS anyway, to prevent DNS spoofing attacks and such
>> (i.e. most attacks that don't need your own machine to be compromised).
>> But maybe additional support for signing the code would be even better,
>> to be able to detect compromised code on the server.
> 
> Yah, I thought of a SHA1 optional parameter:
> 
> pragma(liburl, mylib, "myurl", "mysha1");
> 

With the SHA1 containing the mylibs hash?
That doesn't help much.. if you don't expect the file to change at all
on the server, you can just bundle it with your source.
One great advantage of being able to download code you're depending on
is that the author can bugfix it and you can can easily update, isn't it?

I thought about letting the author sign his code with GPG, e.g. having a
file on the server with signed SHA1 hashes of the files or something
like that.

>>> 3) It only solves the problem for D modules, but not any other possible
>>> dependencies.
>>>
>>> I understand that this is a very urgent problem, but my opinion is that
>>> this half-arsed solution will only delay implementing and cause
>>> migration problems to a real solution, which should be able to handle
>>> svn/hg/git checkout, proper packages with custom build scripts,
>>> versioning, miscellaneous dependencies, publishing, etc.
>>>
>>
>> I personally think that a standard build tool that does this (and
>> possibly also ships with DMD) would be better than support directly in
>> the language.
>> Especially the case that the projects website changes could be handled
>> more easily by adjusting the URL in a config file instead of changing
>> your code.
> 
> This is still possible with D config files that contain pragmas.
> 

OK.
Still, I prefer a build-tool solution. I think that would be easier to
expand to support git etc.

> 
> Andrei

Cheers,
- Daniel