DIP11: Automatic downloading of libraries

[Steven Schveighoffer]

On Wed, 15 Jun 2011 11:23:58 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 6/15/11 10:07 AM, Steven Schveighoffer wrote:
>> On Wed, 15 Jun 2011 10:33:21 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>>> 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.
>>
>> Look at the url again, I'll split out the include path and the import:
>>
>> [http://www.dsource.org/projects/dcollections/import] /
>> [dcollections/TreeMap.di]
>
> I understood the first time. Yes, so it imposes on the url structure  
> that it ends with /dcollections/.

No, that was just because dcollections' home base is  
www.dsource.org.projects/dcollections.  I.e. the fact that the import  
starts with dcollections and the include path contains dcollections are  
not significant.  dget tries all paths just like dmd tries all paths.

>
>> There is nothing being assumed by dget. It could try and import
>> dcollections.TreeMap from some other remote path as well, and fail. It
>> follows the same rules as the current import scheme, just with urls
>> instead of paths.
>
> I don't think it's a good idea to search several paths for a given  
> import. One import should map to two download attempts: one for the .di,  
> next for .d.

In the ideas I've outlined, dget is given include paths, not what packages  
are in those include paths.  So the two attempts are per import path.   
However, this only happens on first usage, after that, they are cached, so  
there is no try-and-fail required.

I can see why you want this, but in order for it to fit in with the  
current import path scheme, it would have to be this way.  Otherwise,  
you'd need a different switch besides -I to implement it (or the pragma).   
Not that those cannot be implemented, but the simplistic "just specify a  
network include path like you would a local one" has appeal to me.

-Steve