DIP11: Automatic downloading of libraries

[Steven Schveighoffer]

On Wed, 15 Jun 2011 12:35:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 6/15/11 11:00 AM, Adam D. Ruppe wrote:
>>> I understand the appeal, but I also understand the inherent
>>> limitations of HTTP versus a file system. I don't think it's wise
>>> pounding the former into the shape of the other.
>>
>>
>> AIUI, you can't search for a module on a local filesystem either,
>> aside from guessing a name. In D, a module name doesn't necessarily
>> have to match the file name.
>>
>> If you import foo.bar;, you have two options:
>>
>> call it foo/bar.d
>>
>> pass whatever.d that has "module foo.bar;" in it on the command
>> line explicitly.
>>
>>
>> Being able to do a list directory entries feature doesn't really
>> help locate a given named D module anyway.
>
> OK, good point. Still search is going on across all -I paths, which I  
> think we shouldn't extend to URLs.
>

I thought of a good reason why -Iurl is likely to cause problems:

-Ihttp://xxx.yyy.zzz/package1 -Ihttp://aaa.bbb.ccc/package2

import a;

if xxx.yyy.zzz/package1 and aaa.bbb.ccc/package2 both contain a module  
called a, then which one is used depends on the conditions of the  
network.  For example, xxx.yyy.zzz could go offline momentarily, and so  
package2 is used.  Or xxx.yyy.zzz/package1 could be moved to a different  
url.

I know this is a remote possibility, but like you said, internet urls are  
not the same things as files.

I propose the following:

1. the parameter to -I (called an import path) can have an optional equals  
sign in it.  If the equals sign is present, then the form is:

full.module.path=<path_to_module>

If this is the case, then failure to find full.module.path.x module inside  
the given path is recorded as an error (i.e. no other paths are searched).

2. we have a pragma(importpath, "<valid_import_path>");  which makes dmd  
treat the imports from that specific file as if -I<valid_import_path> was  
first in the path list.  If the imported file is indirect (i.e. foo.d  
imports bar.d which imports baz.d), then the pragma'd path does not count  
when parsing the indirect file.

3. <path_to_module> can be either a file path or a url.

4. remote paths are treated like I've specified elsewhere, where the -I  
parameters of dmd (+ the pragmas) would be passed to dget.

I think this should give us maximum flexibility, and fit within the  
current system quite well -- as well as giving us more specific import  
control even for local paths.

-Steve