envy for "Writing Go Packages"

[Michel Fortin]

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

> Michel Fortin wrote:
>> On 2010-05-07 13:55:34 -0400, Walter Bright <newshound1 at 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 at michelf.com
http://michelf.com/