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?

Bernard Helyer wrote:
> On 08/05/10 11:25, Walter Bright wrote:
>> 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?

Yes. Or perhaps a compiler switch.

On 2010-05-07 19:27:52 -0400, Walter Bright <newshound1@digitalmars.com> said:

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

Well, as soon as you have two modules trying to import a different version of the same module you'll have trouble. What if module main imports foo version 1, foo imports bar, and bar imports foo latest version? It's no issue as long as you don't use the feature, but I can't figure out how you can use it reliably. Versioning generally needs to happen at a bigger granularity than modules, because most of the time modules in the same project depend on each other. (Read below for another approach at versioning.)


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

It's important, it's a security issue. You need to be in control of the code you use. This code will run on your computer, and you might distribute it to others. If I compile a library and the source code triggers the compiler into automatically downloading the newest version of a given module from somewhere on the internet before including it into your program, it is a potential threat if "somewhere on the internet" isn't trusted by those who develop the software.

I like my proposal of extending the import path. We could for instance associate module package names to paths or remote URLs like this:

	michelf.*   http://d.michelf.com/repo/
	*           /usr/local/d/
	*           http://dsource.org/repo/

Ok, that's more in the form of a configuration file, but you get the point: you can tell that files from the package michelf should be searched at the given URL, while every other files must be searched in /usr/local/d/, then if it fails they're searched on dsource.org. If someone wants to use a local copy, he replaces URLs with local path as we currently do, or if he wants to use his own proxy server (where libraries presumably get audited and approved) then he use that URL.

If someone wants a different version for a given package, he specifies a different URL or path for that version. The setting will apply to a whole package (and its subpackages) and every import from every module will use the version you asked, not just the module that wanted a specific version. Example configuration:

	michelf.reflex.*   http://d.michelf.com/repo/1.1/
	michelf.*          http://d.michelf.com/repo/trunk/
	*                  /usr/local/d/
	*                  http://dsource.org/repo/

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

Bernard Helyer wrote:
> 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?


I'd like to emphasize that this idea is specifically about not having to install anything. You just type the correct package name in the import declaration, and the compiler system takes care of the rest.

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.

Not at all. Some builds want to peg the code against a specific version, so they encode that in the path. Some others may just want to use the latest, so they'd import http.d_repository.foo.current. On the server, current is always aliased to the latest.

This scheme is used everywhere on Unix.

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

When I delivered my book, my publisher asked me to send them all LaTeX packages I used. I replied, "they're the system-provided packages coming with LiveTeX x.y.z". They insisted they need the exact files so they have them. It's not at all uncommon (albeit sad) that software is built for a very specific version of some software. My employer has huge issues m

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

That's a good point. At a minimum, there should be the possibility to define aliases like this:

alias http.erdani.com.tdpl.code tdpl;
...
import tdpl.stuff;

Then the alias definition becomes a unique point of maintenance. Unfortunately something like that doesn't currently work, so if the online modules feature is introduced, we need to introduce such aliases as well.

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

Yah. Unfortunately other languages don't have it so it's difficult to learn from others' experience.


Andrei

Walter Bright wrote:
> Bernard Helyer wrote:
>> 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?
> 
> 
> I'd like to emphasize that this idea is specifically about not having to install anything. You just type the correct package name in the import declaration, and the compiler system takes care of the rest.

He meant something else - the fact that changing one's mind about a package's location (remote vs. local) entails doing surgery on the source code.

Andrei

Hello Walter,

> I kind of like the idea that it shouldn't install D packages, but
> rather cache them from the web repository.
> 

One absolute must in my book is that it be trivial to get a build working without any external dependencies. Tweaking lots of import paths is not trivial. Some users won't use a system that isn't set up for that. Two things that come to mind are 1) a mandate that "everything needed to build must be checked into source control" and 2) a project where the owner, for security reasons, wanted to be sure that all external dependencies (compiler, libs, etc.) predated the code that depended on them. 

-- 
... <IXOYE><

:Hello Walter,

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

A "the internet is here: <path>" flag would do the trick.

-- 
... <IXOYE><

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.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
'It's not you, it's me....'? You're giving me the 'It's not you, it's me'
routine? I invented 'It's not you, it's me.' Nobody tells me it's them,
not me. If it's anybody, it's me.
	-- George Constanza

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.

-- 
... <IXOYE><