"Leandro Lucarella" <llucax@gmail.com> wrote in message news:20100508011012.GA32072@llucax.com.ar...
> Walter Bright, el  7 de mayo a las 13:18 me escribiste:
>> Johan Granberg wrote:
>> >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
>> >
>> >If I was administering a server or multiuser system or linux
>> >distribution I
>> >would care, being able to install packages and libraries globaly for all
>> >users easily can be important.
>>
>> The caching should handle that transparently.
>
> Already done:
> http://0install.net/
>
> Too bad (or good?) nobody uses or know it.
>

That looks absolutely awesome! My only little concern is that it's written in python, I had to use bazaar to do something one time and it was insanely slow.

Bernard Helyer <b.helyer@gmail.com> wrote:

> On 08/05/10 11:25, Walter Bright wrote:
>> Rainer Deyke wrote:
>>> I like this. The only question is, how do you handle computers without
>>> an internet connection?
>>
>> It can also be a LAN connection if the sys admin sets up a local
>> repository.
>>
>> But essentially, what we are talking about is distribution over the
>> internet and a central internet repository, so it won't work if you're
>> not connected. It's basically cloud compiling.
>>
>> If you want to work off line, then you can do the extra steps necessary
>> to install it locally.
>
>
> I guess the trouble is if you use a special syntax like `import http.`, then one has to modify the source of the application to install it locally, no?

Depends on the system, of course. The local install could still keep the
URI information, e.g. by means of directory structure or a library
configuration file.

-- 
Simen

BCS wrote:

> Hello Walter,
> 
>> You just type the correct package name in the
>> import declaration, and the compiler system takes care of the rest.
> 
> How about a package->source mapping?
> 
> dmd -I my.corp=http://mycorp.com/sourcerepo
> 
> import my.corp.foo; // looked for at http://mycorp.com/sourcerepo.foo.d
> 
> that way when things move, or corps merg, you only need to update the mappings.
> 

I like that idea, naming specific remote locations of a package all over the place in the source code seems a bit flaky.

This way you can also more easily specify whether you want to use a local install only, download as needed, or a 'lazy-install' which installs as needed, checking for updates, etc. It starts to look a bit like dsss :)

The specific package -> source mappings could located in any one of:
- in a pragma
- on the command line
- in a repository listing, either remotely or locally specified

On Sat, 08 May 2010 02:07:29 +0000, BCS wrote:

> Hello Walter,
> 
>> You just type the correct package name in the import declaration, and the compiler system takes care of the rest.
> 
> How about a package->source mapping?
> 
> dmd -I my.corp=http://mycorp.com/sourcerepo
> 
> import my.corp.foo; // looked for at http://mycorp.com/sourcerepo.foo.d
> 
> that way when things move, or corps merg, you only need to update the mappings.


I think that's a really good idea.

-Lars

Nick Sabalausky, el  7 de mayo a las 22:36 me escribiste:
> >> The caching should handle that transparently.
> >
> > Already done:
> > http://0install.net/
> >
> > Too bad (or good?) nobody uses or know it.
> >
> 
> That looks absolutely awesome! My only little concern is that it's written in python, I had to use bazaar to do something one time and it was insanely slow.

I think your bottleneck will be your internet connection ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Oiganmen ñatos de corazón, es más posible que un potus florezca en
primavera a que un ángel pase con una remera.
	-- Peperino Pómoro

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.

"Leandro Lucarella" <llucax@gmail.com> wrote in message news:20100508173421.GA8076@llucax.com.ar...
> Nick Sabalausky, el  7 de mayo a las 22:36 me escribiste:
>> >> The caching should handle that transparently.
>> >
>> > Already done:
>> > http://0install.net/
>> >
>> > Too bad (or good?) nobody uses or know it.
>> >
>>
>> That looks absolutely awesome! My only little concern is that it's
>> written
>> in python, I had to use bazaar to do something one time and it was
>> insanely
>> slow.
>
> I think your bottleneck will be your internet connection ;)
>

Good point. It may very well have been just a slow connection to whatever particular server it was. Heh :)

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

Robert Clipsham <robert@octarineparrot.com> wrote:

> How about:
>
> @remote import foo.bar.baz.ver1_23;

Why invent a new keyword? Surely this is a match for extern:

extern import foo.bar.baz.vert1_23;

-- 
Simen

On 08/05/10 21:26, Nick Sabalausky wrote:
> 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%/

Good point! Doing this means it can be done now too, no language changes needed (except maybe to remove the .ver1_23... how would the compiler know when to do this though?). Other than that, I like it!