DIP11: Automatic downloading of libraries

[Andrei Alexandrescu]

On 6/15/11 9:13 AM, Steven Schveighoffer wrote:
> 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?

That doesn't mean the situation is beyond improvement. If I had my way 
I'd add pragma(liburl) AND pragma(libpath).

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

Because in the former case the whole need for a build script may be 
obviated. That's where I'm trying to be.

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

Sounds good. I actually had the same notion, just forgot to mention it 
in the dip (fixed).

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

This assumes the URL contains the package prefix. That would work, but 
imposes too much on the URL structure. I find the notation -Upackage=url 
more general.

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

Sounds cool.


Andrei