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

newer
hackage, cabal-get, and security

older
Problem with Editor Combinators

Simon Marlow

18 May 2005 18 May '05

4 a.m.

On 17 May 2005 17:14, S. Alexander Jacobson wrote:

...

...
- versioning

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? Cheers, Simon

Show replies by date

S. Alexander Jacobson

18 May 18 May

12:58 p.m.

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

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?

With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package? 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. The advantage of SearchPath over the status quo is that its module maps make this universe explicit and versionable rather than tacit and unidentifiable. The value of explicit shared module maps is that you increase the likelihood that module authors and users will actually agree on module meanings. For example, both author and user can use the map at haskell.org. If they are in the same organization, they can ALSO use their organization's module map (inheriting some meanings from haskell.org and overriding others). They can also use their division's module map inheriting from their organizations map, etc. The implicit maps of Cabal's "build-depends" are an invitation for conflict. You have no particularly good reason to assume that any two packages will be compatible. Worse, you have no particularly good reason to assume that the user of your package will be able to *find* the packages on which it depends. Thus you try to minimize code reuse. SearchPath's explicit shared module maps makes it much less likely that author and user will end up with different meanings for a particular module name and make it much less likly that the user won't be able to resolve module dependencies, making code reuse much more likely. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

Isaac Jones

1:11 p.m.

New subject: SearchPath

"S. Alexander Jacobson" writes:

...

With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package?

That's specified by the dreaded build-depends field, of course.

...

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.

The advantage of SearchPath over the status quo is that its module maps make this universe explicit and versionable rather than tacit and unidentifiable.

There you go again. (snip)

...

The implicit maps of Cabal's "build-depends" are an invitation for conflict.

What's implicit about build-depends again?

...

You have no particularly good reason to assume that any two packages will be compatible.

You don't have to assume anything. The packager tells you which packages are compatible. (snip)

...

SearchPath's explicit shared module maps makes it much less likely that author and user will end up with different meanings for a particular module name and make it much less likly that the user won't be able to resolve module dependencies, making code reuse much more likely.

You're comparing apples to oranges. Hackage (not cabal) ensures that the end user can resolve module dependencies. peace, isaac

S. Alexander Jacobson

1:41 p.m.

New subject: SearchPath

On Wed, 18 May 2005, Isaac Jones wrote:

...

"S. Alexander Jacobson" writes:

...
With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package?

That's specified by the dreaded build-depends field, of course.

So you like to use packages P1 and P2. You've decided to build a program that uses both of them. How does build-depends tell you that they both don't use the same hidden module name? Or suppose that P1 build-depends on P3 and P2 depends on P4 and both P3 and P4 expose the same module name. With build-depends, you don't discover these sorts of conflicts until you happen to use packages together. Module maps give you a promise that a set of packages are compatible with one another (don't overlap).

...

...
The implicit maps of Cabal's "build-depends" are an invitation for conflict.

What's implicit about build-depends again?

The dependency graph that propagates from any package.

...

...
You have no particularly good reason to assume that any two packages will be compatible.

You don't have to assume anything. The packager tells you which packages are compatible.

The packager CAN'T tell you which packages are compatible. An build-depends arbitrarily far away in the implicit dependency graph can cause conflict.

...

...
SearchPath's explicit shared module maps makes it much less likely that author and user will end up with different meanings for a particular module name and make it much less likly that the user won't be able to resolve module dependencies, making code reuse much more likely.

You're comparing apples to oranges. Hackage (not cabal) ensures that the end user can resolve module dependencies.

I don't think Hackage provides a mapping from module names to packages. You talked about adding such a facility in this thread, but even if you do, Hackage provides you with no simple way to tell that the package you choose to implement the module will be compatible with the other packages you are using. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

Duncan Coutts

19 May 19 May

7:36 a.m.

New subject: SearchPath

On Wed, 2005-05-18 at 13:41 -0400, S. Alexander Jacobson wrote:

...

On Wed, 18 May 2005, Isaac Jones wrote:

...
"S. Alexander Jacobson" writes:

...
With Cabal, if you download two packages, how do you know that they won't require conflicting versions of another module/package?

That's specified by the dreaded build-depends field, of course.

So you like to use packages P1 and P2. You've decided to build a program that uses both of them. How does build-depends tell you that they both don't use the same hidden module name?

Or suppose that P1 build-depends on P3 and P2 depends on P4 and both P3 and P4 expose the same module name.

With build-depends, you don't discover these sorts of conflicts until you happen to use packages together.

Module maps give you a promise that a set of packages are compatible with one another (don't overlap).

Actually, I think that this can be done with the cabal "build-depends". Each .cabal file says which modules the package exposes and which are hidden (although for our purposes of ensuring no overlaps the visible/hidden distinction is irrelevant). So all we do is trace the modules provided by the package in question and all modules provided by all packages it "build-depends" upon, and so on recursively. This gives us the complete set of modules used by a package and so we can see if two packages are compatible by checking if their module sets overlap, and if they do overlap we can see if any of the overlapping modules have different .hi files (or just the .hi file paths would probably be sufficient). This does ignore the current problem of modules that are provided by exposed packages are effectively part of your program's module set wether or not use use them or any modules from packages which use them (see the 'hslibs' problem). Duncan

7307

Age (days ago)

7308

Last active (days ago)

List overview

Download

4 comments

4 participants

participants (4)

Duncan Coutts
Isaac Jones
S. Alexander Jacobson
Simon Marlow