"Robert Clipsham" <rob...@octarineparrot.com> wrote in message news:hs4f66$1a1...@digitalmars.com... > On 07/05/10 18:55, Walter Bright wrote: >> Jacob Carlborg wrote: >>> Should it also contain something similar to rdmd? >> >> I kind of like the idea that it shouldn't install D packages, but rather >> cache them from the web repository. It would be convenient because: >> >> 1. who actually cares about installing the packages >> 2. backups are automatic >> 3. your actual project is small and easily moved to another machine >> 4. it becomes trivial to use >> >> Source code could look something like: >> >> import http.d_repository.foo.version1_23; >> >> and the compiler could interpret "http" as meaning the rest is an >> internet url, foo is the package name, and version1_23 is the particular >> version of it. > > How about: > > @remote import foo.bar.baz.ver1_23; > > Then passing -R "http://repo.example.com/tag/%VERSION%/%PACKAGE%/" as a > compiler/build tool (see below) switch? This way you don't have to mangle > URLs to be valid D identifiers, the http.* namespace doesn't get eaten, > and the user can specify a custom layout to get the given package/version. > > Doing it this way makes it completely possible for this kind of tool not > to be built into the compiler too, as @remote can be eaten and ignored by > the compiler, but added to json output. Then something such as xfbuild can > check for it and get the package as an archive, check it out from an > svn/hg/git/etc repository etc, removing the need for a load of funky code > to handle it from the compiler.
I don't see what benefit having the "@remote" there provides. Why not just: import foo.bar.baz.ver1_23; dmd -R:foo.bar.baz=http://repo.example.com/tag/%VERSION%/%PACKAGE%/