DIP11: Automatic downloading of libraries

[Steven Schveighoffer]

On Wed, 15 Jun 2011 23:23:43 -0400, Ary Manzana <ary at esperanto.org.ar>  
wrote:

> On 6/15/11 8:33 PM, Steven Schveighoffer wrote:
>> On Tue, 14 Jun 2011 09:53:16 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>>
>>> Destroy.
>>
>> I put this as replies in several threads, but I'll throw it out there as
>> its own thread:
>>
>> * You already agree that having the fetching done by a separate program
>> (possibly written in d) makes the solution cleaner (i.e. you are not
>> infiltrating the code that actually does compiling with code that does
>> network fetching).
>>
>> * I think specifying the entire url in the pragma is akin to specifying
>> the full path of a given module on your local disk. I think it's not the
>> right place for it, the person who is building the code should be
>> responsible for where the modules come from, and import should continue
>> to specify the module relative to the include path.
>>
>> * A perfect (IMO) way to configure the fetch tool is by using the same
>> mechanism that configures dmd on how to get modules -- the include path.
>> For instance -Ihttp://xxx.yyy.zzz/package can be passed to the compiler
>> or put into the dmd.conf.
>>
>> * DMD already has a good mechanism to specify configuration and you
>> would barely have to change anything internally.
>>
>> Here's how it would work. I'll specify how it goes from command line to
>> final (note the http path is not a valid path, it's just an example):
>>
>> dmd -Ihttp://www.dsource.org/projects/dcollections/import testproj.d
>>
>> 1. dmd recognizes the url pattern and stores this as an 'external' path
>> 2. dmd reads the file testproj.d and sees that it imports
>> dcollections.TreeMap
>> 3. Using it's non-external paths, it cannot find the module.
>> 4. It calls:
>> dget -Ihttp://www.dsource.org/projects/dcollections/import
>> dcollections.TreeMap
>> 5. dget checks its internal cache to see if the file
>> dcollections/TreeMap.[d|di] already exists -- not found
>> 6. dget uses internal logic to generate a request to download either
>> a. an entire package which contains the requested import (preferred)
>> b. just the specific file dcollections/TreeMap.d
>> 7. Using the url as a key, it stores the TreeMap.d file in a cache so it
>> doesn't have to download it again (can be stored globally or local to
>> the user/project)
>> 8. Pipes the file to stdout, dmd reads the file, and returns 0 for  
>> success
>> 9. dmd finishes compiling.
>
> So if I have a library with three modules, a.d, b.d, c.d, which depend  
> on another library, I should put that pragma(importpath) on each of them  
> with the same url?

With the updated proposal (please see the DIP now), you can do -I to  
specify the import path on the command line.  Otherwise, yes, you have to  
duplicate it.

> Or maybe I could create a fake d file with that pragma, and make the  
> three modules import it so I just specify it once.

As long as the fake d file imports the files you need publicly, it should  
be pulled in, yes.  But the import pragma only affects imports from the  
current file.  I think that seems right, because you don't want to worry  
about importing files that might affect your import paths.  I look at it  
like version statements.

-Steve