envy for "Writing Go Packages"

[Nick Sabalausky]

"Robert Clipsham" <robert at octarineparrot.com> wrote in message 
news:hs4f66$1a1i$1 at 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%/