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.

Leandro Lucarella wrote:

> Graham Fawcett, el  7 de mayo a las 11:55 me escribiste:
>> Hi BCS,
> 
> Let me add:
> 
> * It integrates well with existing packaging systems (dpkg, rpm, etc.).
>   I hate installing stuff outside my distro's packaging system. A simple:
>   d-pkg builddeb
>   should leave you a nice Debian package to install using dpkg, for
>   example. And you might think that I'm just being lazy, but no, this is
>   essential to have a good acceptance among Linux distribution, which
>   means more distribution of D software. Having this makes trivial for
>   packagers to pack D software, which means you can do: apt-get install
>   d-software easily, which means reaching more people that doesn't have
>   a D compiler, but want to enjoy D software.
> 

I would love to see this.

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.

> 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.

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.

Walter Bright wrote:

> 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.

I have yet to see a system where that works. How can an administrator chose to install a set of libraries in such a setup? Will it still work if the net conectivity is not always present (laptop). Can a linux distribution use that to ensure that some libraries are always pressent?

Consider that users might not have the dissk quota to allways have their own copies of every library imaginable installed.

Experiance from working with debian systems is that the languages that tries to make their own solutions for automatic handling and caching and so on fails badly, while those integrating/packaging as deb packages works fine. Problems seems to apear either when trying to install for all users or when installing in a users home directory.

On 5/7/2010 11:55, Walter Bright wrote:
> 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.

I like this.  The only question is, how do you handle computers without an internet connection?


-- 
Rainer Deyke - rainerd@eldwood.com

On 2010-05-07 13:55:34 -0400, Walter Bright <newshound1@digitalmars.com> said:

> 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.

So now, each time a new version of a library pops up you need to search-replace the version number for all your source code, and source code of other library you depend on? This is insane.

The version number shouldn't be there, except perhaps if it's a 'major' version number full of breaking changes.

Also, putting in the source code the location or protocol to fetch the repository isn't much better. There's a reason we have a module import path: so that finding external code depends on compile-time configuration, not on the actual code you build.

Allowing URLs in the import path might be an interesting idea though.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Johan Granberg wrote:
> Walter Bright wrote:
> 
>> 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.
> 
> I have yet to see a system where that works.

I think the internet browser is an example.

? How can an administrator chose
> to install a set of libraries in such a setup?

Essentially, he doesn't, because the libraries are not installed. The build process looks in the temporary cache for the files, and uses them if they're there, otherwise it downloads them off the network and puts them in the temporary cache. They are never actually installed.

> Will it still work if the net conectivity is not always present (laptop).

No, it will not, unless the files happen to already be in the cache. The builder will look in the cache first for the files.

> Can a linux distribution
> use that to ensure that some libraries are always pressent?

If that is desired, then they can be actually installed by the administrator.

> Consider that users might not have the dissk quota to allways have their own
> copies of every library imaginable installed.

Being a cache, the least recently used library can always be kicked out, and then reloaded as necessary. Think of it working like the temporary cache for your browser.


> Experiance from working with debian systems is that the languages that tries
> to make their own solutions for automatic handling and caching and so on
> fails badly, while those integrating/packaging as deb packages works fine.
> Problems seems to apear either when trying to install for all users or when
> installing in a users home directory.

These problems are all sidestepped because the libraries won't be installed. It's a wholly different way of doing things.

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.

Michel Fortin wrote:
> On 2010-05-07 13:55:34 -0400, Walter Bright <newshound1@digitalmars.com> said:
> 
>> 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.
> 
> So now, each time a new version of a library pops up you need to search-replace the version number for all your source code, and source code of other library you depend on? This is insane.
> 
> The version number shouldn't be there, except perhaps if it's a 'major' version number full of breaking changes.

If you leave the version number off, it gets the latest version. If you put it on, it reliably stays the same. I don't see an issue.


> Also, putting in the source code the location or protocol to fetch the repository isn't much better. There's a reason we have a module import path: so that finding external code depends on compile-time configuration, not on the actual code you build.

It's a good point, but I think it's a detail.

> Allowing URLs in the import path might be an interesting idea though.