On 2010-05-07 19:27:52 -0400, Walter Bright <[email protected]> said:
Michel Fortin wrote:
On 2010-05-07 13:55:34 -0400, Walter Bright <[email protected]> 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
[email protected]
http://michelf.com/
