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

On 6/15/11 10:07 AM, Steven Schveighoffer wrote:
On Wed, 15 Jun 2011 10:33:21 -0400, Andrei Alexandrescu
<seewebsiteforem...@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

Reply via email to