SearchPath

[S. Alexander Jacobson]

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" <alex at alexjacobson.com> 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 at syntaxpolice.org **
>