"S. Alexander Jacobson"
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