Re: SearchPath

18 May 2005

      On Tue, 17 May 2005, Isaac Jones wrote:
...
Well, the 'hackage' way to do this is to do the reverse lookup I
mentioned, download the package, and add the -package flag while
you're building, rather than downloading individual modules.  It'll
look the same from the end-user's perspectivce, though.
Yes, my point with SearchPath is to factor hackage down to the bare 
minimum of being a system for looking up where modules reside.  If 
they reside in a package, then of course it should download the 
package and install it.
...
I don't understand.  If you use hackage to get from module names to
packages and / or .cabal files, then what else do you need?
A difference perhaps is that SearchPath integrates grabbing 
dependencies into the edit/compile/debug cycle rather keeping it 
separate.

Things I'd like to know.

1. Is there a programmatic way to detect what packages are installed 
or do I have to shell out to ghc-pkg?

2. Is the name in the cabal file guaranteed to match the name exposed 
by ghc-pkg?

3. Can I access the source of all exposed modules in an installed 
package to enumerate its external module dependencies and import 
chase?

4. If you have an unpacked package in a directory, is there a path 
from the cabal file to the relative paths of each file in the package?
(so you can point at a repository rather than a tarball and access 
it via http).

5. Given that module names are absolute, if you have another way to 
find external modules required by a package (e.g. SearchPath or 
perhaps hackage reverse lookup), can you ignore build-depends?

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

On Tue, 17 May 2005, Isaac Jones wrote:
...
"S. Alexander Jacobson"  writes:
...
On Tue, 17 May 2005, Isaac Jones wrote:
...
You'd just need a way to map module names to package names / versions.
Actually, that's the easy part.  For example, right now my test map
file is:
HAppS      http://happs.org
   *.*.HaXml  http://www.cs.york.ac.uk/fp/darcs/HaXml/src
So, any module that starts with HAppS can be found at HAppS.org.  And
any module with HaXml at the third level of hierarchy can be found in
the York HaXml darcs repository. e.g. it does this sort of
transformation:
HAppS.ACID -> http://happs.org/HAppS/Acid.(hs|lhs)
   Text.XML.HaXml.Escape -> http://www.cs.york.ac.uk/fp/darcs/HaXml/src/Text/XML/HaXml/Escape.(hs|lhs)
Once if finds a module, SearchPath downloads it, put it a directory
for that map file, and add that directory to the module search path.
However, right now it only knows how to find modules in
directories. It would be nice if the URL could point to a Package file
rather than a base directory and SearchPath knew how to detect whether
it is already installed, install it if not, and import chase all its
modules.
Well, the 'hackage' way to do this is to do the reverse lookup I
mentioned, download the package, and add the -package flag while
you're building, rather than downloading individual modules.  It'll
look the same from the end-user's perspectivce, though.
...
It would be even nicer if the URL could point to Cabal files and
SearchPath knew from the Cabal files what else it needed to download
to build the package so that the package author can use the URL of a
cabal file in a repository and doesn't need to bother dealing with
producing tarballs for each version.
I don't understand.  If you use hackage to get from module names to
packages and / or .cabal files, then what else do you need?
peace,
isaac
** CRM114 Whitelisted by: ijones@syntaxpolice.org **