DIP11: Automatic downloading of libraries

[Steven Schveighoffer]

On Wed, 15 Jun 2011 09:53:31 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 6/15/11 7:53 AM, Steven Schveighoffer wrote:
>> On Tue, 14 Jun 2011 16:47:01 -0400, Adam D. Ruppe
>> <destructionator at gmail.com> wrote:
>>
>>> BTW, I don't think it should be limited to just passing a
>>> url to the helper program.
>>>
>>> I'd do it something like this:
>>>
>>> dget module.name url_from_pragma
>>
>> I still don't like the url being stored in the source file -- where
>> *specifically* on the network to get the file has nothing to do with
>> compiling the code, and fixing a path problem shouldn't involve editing
>> a source file -- there is too much risk.
>
> First, clearly we need command-line equivalents for the pragmas. They  
> can be subsequently loaded from a config file. The embedded URLs are for  
> people who want to distribute libraries without requiring their users to  
> change their config files. I think that simplifies matters for many.  
> Again - the ULTIMATE place where dependencies exist is in the source  
> files.

We have been getting along swimmingly without pragmas for adding local  
include paths.  Why do we need to add them using pragmas for network  
include paths?

Also, I don't see the major difference in someone who's making a piece of  
software from adding the include path to their source file vs. adding it  
to their build script.

But in any case, it doesn't matter if both options are available -- it  
doesn't hurt to have a pragma option as long as a config option is  
available.  I just don't want to *require* the pragma solution.

>
>> For comparison, you don't have to specify a full path to the compiler of
>> where to get modules, they are specified relative to the configured
>> include paths. I think this model works well, and we should be able to
>> re-use it for this purpose also. You could even just use urls as include
>> paths:
>>
>> -Ihttp://www.dsource.org/projects/dcollections/import
>
> I also think that model works well, except HTTP does not offer search  
> the same way a filesystem does. You could do that with FTP though.

dget would just add the appropriate path:

import dcollections.TreeMap =>
get  
http://www.dsource.org/projects/dcollections/import/dcollections/TreeMap.d
hm.. doesn't work
get  
http://www.dsource.org/projects/dcollections/import/dcollections/TreeMap.di
ok, there it is!

As I said in another post, you could also specify a zip file or tarball as  
a base path, and the whole package is downloaded instead.  We may need  
some sort of manifest instead in order to verify the import will be found  
instead of downloading the entire package to find out.

-Steve