RE: SearchPath (was RE: hackage, cabal-get, and security)
On 18 May 2005 17:59, S. Alexander Jacobson wrote:
On Wed, 18 May 2005, Simon Marlow wrote:
On 17 May 2005 17:14, S. Alexander Jacobson wrote:
With SearchPath, you supply the URLs of the module maps you want to use. SearchPath then uses these map to locate, download and "install" needed libraries without further user intervention.
A module map is just a file mapping module names to the base URLs of directories in which they reside. If you want to supply the URL of a particular version of a module map rather than "latest" you are free to do that.
But how do you know what module maps were being used by the author of the module you download? Don't you have to download their module map file too?
The reality is that, no matter what, you always have to assume that the user and author of a particular module/package need to live in basically the same universe of modules and packages.
So in fact I *cannot* locally modify my module map to use a different version of an imported module. The module map is fixed and global, although I can extend it locally. So basically, there's no versioning, because everyone has to use the same version of everything. Right? Well, except that I can enter into a pact with another module author to use a certain version of a third party's module, and we both have to remember that we have the pact because the information doesn't travel with the module sources (unlike Cabal, where dependencies are explicit, I might add).
With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package?
As discussed before, the fact that you can't use two versions of a package simultaneously is a missing feature in the implementation, nothing more. Cheers, Simon
On Wed, 18 May 2005, Simon Marlow wrote:
With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package?
As discussed before, the fact that you can't use two versions of a package simultaneously is a missing feature in the implementation, nothing more.
I thought we agreed that module names are absolute (not package qualified). As such, if two modules use the same module name to mean two different things they are *in principle* incompatible. You can't fix this in the implementation without changing the meaning of the language. Moreover since module names are absolute, the mapping of module names to implementation must be global to a program and not local to a particular package. The only question is whether this mapping is implicit or explicit. SearchPaths' module maps make it explicit.
(unlike Cabal, where dependencies are explicit, I might add).
Actually, only the immediate dependencies of a Cabal package are explicit. A Cabal package is actually dependent on a much larger graph of packages connected through build-depends relations. And since build-depends relations include open version intervals, this graph may change silently and catastrophically over time. Module maps is to make the *full* set of dependencies explicit and make it more likely that all modules/packages will be compatible.
The reality is that, no matter what, you always have to assume that the user and author of a particular module/package need to live in basically the same universe of modules and packages.
So basically, there's no versioning, because everyone has to use the same version of everything. Right? Well, except that I can enter into a pact with another module author to use a certain version of a third party's module, and we both have to remember that we have the pact because the information doesn't travel with the module sources
If you develop a new version of a particular package P1, install it locally on your system, and rely on it in developing package P2 which you then publish. You would of course not be surprised when people discover they can't use P2 because it depends on a not yet public version of P1. In practice, you would not publish P2 until you have ALSO published P1. Nothing really changes with SearchPath. You publish P1 to a shared module map and then you publish P2. The only change is that with module maps, you can now guarantee that these changes don't break compatibility with any other packages in the set. If you rely solely on build-depends, you never really know. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On 18 May 2005 17:59, S. Alexander Jacobson wrote:
On Wed, 18 May 2005, Simon Marlow wrote:
On 17 May 2005 17:14, S. Alexander Jacobson wrote:
With SearchPath, you supply the URLs of the module maps you want to use. SearchPath then uses these map to locate, download and "install" needed libraries without further user intervention.
A module map is just a file mapping module names to the base URLs of directories in which they reside. If you want to supply the URL of a particular version of a module map rather than "latest" you are free to do that.
But how do you know what module maps were being used by the author of the module you download? Don't you have to download their module map file too?
The reality is that, no matter what, you always have to assume that the user and author of a particular module/package need to live in basically the same universe of modules and packages.
So in fact I *cannot* locally modify my module map to use a different version of an imported module. The module map is fixed and global, although I can extend it locally.
So basically, there's no versioning, because everyone has to use the same version of everything. Right? Well, except that I can enter into a pact with another module author to use a certain version of a third party's module, and we both have to remember that we have the pact because the information doesn't travel with the module sources (unlike Cabal, where dependencies are explicit, I might add).
With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package?
As discussed before, the fact that you can't use two versions of a package simultaneously is a missing feature in the implementation, nothing more.
Cheers, Simon
** CRM114 Whitelisted by: ijones@syntaxpolice.org **
participants (2)
-
S. Alexander Jacobson -
Simon Marlow