DIP11: Automatic downloading of libraries

[Steven Schveighoffer]

On Tue, 14 Jun 2011 15:14:28 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 6/14/11 1:58 PM, Steven Schveighoffer wrote:
>> I think it should be split as follows:
>>
>> dmd: determine *what* to download (i.e. I need to import module x.y.z)
>
> It can't (unless it does the download too) due to transitive  
> dependencies.

dmd: I need module foo.awesome.  Where is it?
filesystem: nope, don't have it
dmd: damn, I guess I'll need to check with the downloader, hey downloader  
you have that?
downloader: hm... oh, yeah!  I'll get it for you
filesystem: got it
dmd: ok, now what's in foo.awesome?  Oh, hm... foo.awesome needs  
bar.gnarly.  Let me guess filesystem...
filesystem: yeah, I suck today, go ask downloader
...

How hard is that?  I mean the actual downloading of files is pretty  
straightforward, at some point the problem reduces to "download a file".   
Why do we have to reinvent *that* wheel.

>
>> external tool: determine *where* and *how* to download it. (i.e. module
>> x.y.z lives on http://somerepository.org/x, go get it and save it)
>>
>> The advantages being:
>>
>> 1. there exists umpteen billion already-existing tools that fetch and
>> install data over the network
>> 2. dmd does not contain parts that have nothing to do with compiling,
>> which could potentially screw up the compiling part.
>> 3. Depending on the tool language, the barrier to development of it
>> would be significantly reduced. Most people feel quite uncomfortable
>> messing with compiler source code, but have no problems editing
>> something like a shell script, or even a simple d-based tool.
>> 4. The compiler is written in C++, and hence so would the part that does
>> this have to be... yuck!
>
> Not sure I grok 3 and 4, but as far as I can tell the crux of the matter  
> is that dependencies are already embedded in .d files. That's why I  
> think it's simpler to just let dmd take care of them all instead of  
> maintaining dependency description files in separation from the .d files.

And it would, why wouldn't it?  I think you may not be getting something  
here...

> The umpteen billion tools don't know what it takes to download and build  
> everything starting from one or a few root modules. They could execute  
> the download, yes (and of course we'll use such a library for that), but  
> we need a means to drive them.

dmd would drive them.

> I think Adam's tool is a good identification and alternative solution  
> for the problem that the pragma solves.

I haven't seen it.  Just thinking out loud...

-Steve