envy for "Writing Go Packages"

[Robert Clipsham]

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.