SearchPath (was RE: hackage, cabal-get, and security)

[S. Alexander Jacobson]

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 at syntaxpolice.org **
>