RE: mapping module identifiers to URLs (was RE: [Haskell] URLs in haskellmodule namespace)
On 29 March 2005 22:47, S. Alexander Jacobson wrote:
Here is a strawman proposal for replacing -i.
The compiler/interpreter should accept a "Modules" file that maps thid party module identifiers to URLs at which source may be found. Here is a strawman file format:
#moduleId url(s) Foo.Bar.* http://domain.com/package-v1.0.hkg http://domain.com/package-v2.0.hkg Foo.Bar http://domain2.com/package2.hkg
The urls on any line enumerate all packages that have compatible implementations of the module identified by the module identifier on that line.
Each imported packages may contain at most one Modules file. The implementation attempts to find module URL implementation agreement among all imported packages. If that fails, foreign Modules files are interpreted as being included at the line where they were imported. Later URLs for the same moduleId override earlier ones.
The implementation should give a warning if third party packages give conflicting module locations.
Note: Yes, I know about Cabal's Build-Depends, but it doesn't serve the need described here.
It is true that Cabal's Build-Depends doesn't do everything you want it to, but your proposal also duplicates some of the functionality of Build-Depends, and makes it so that there are two places where dependencies are stored. We should only have to specify dependencies once. Rather than have a separate file to list dependencies, I'd like to see Cabal extended. Downloading and installing dependencies isn't something that should be done by the compiler: we have layered the package system in such a way that the compiler only needs to understand what packages are installed and which ones to use, and the other tools are responsible for arranging to download, build, and install packages. I don't think it's necessary to specify dependencies with module granularity. This just increases the number of possible error cases, without adding functionality. If you want to specify which module imports require each package dependency, then do it with a comment. The tools can tell you if any dependencies are redundant. Suppose that: - Package dependencies in Build-Depends could be specified using URLs. - Cabal could download, build, and install dependencies without any user intervention. That does everything you want, doesn't it? I don't think everyone would want this level of automation (eg. if you want your system's native package manager involved in package installation), but that's a separate matter. Cheers, Simon
A major problem in every major language I have ever used is module systems that make it all too easy for untracked dependencies to creep silently into code. The result has repeatedly been nasty surprises when moving code between machines. A Haskell example of this problem might look something like this: * Oh, Network.HTTP is non-standard!? Thats wierd. * Uh Oh. Google reveals at least three different implementations... * Now, how do I determine which one is installed here? * Is there a local copy of the package somewhere? * No? Ok, is it available for download somewhere? * Uhm, is the version I am using still available for download? * Oh, we made local changes too!? What were they? * Ok, we added Network.Socket.SSL. That's standard right? [rinse/repeat] [A lot of detective work later...] * Ok, now we've figured out all the packages, how do we ship them? [shipping strategy devised...] * But what happens if I don't have root/admin on the target machine? [...] * Oh, this package conflicts with something already installed? [etc.]
It is true that Cabal's Build-Depends doesn't do everything you want it to, but your proposal also duplicates some of the functionality of Build-Depends, and makes it so that there are two places where dependencies are stored. We should only have to specify dependencies once.
I agree you should only have to specify dependencies once. But, deferring dependency tracking to the point you are ready to ship (with Cabal or otherwise) is a recipe for disaster. Every code dependency should be explicit and verified at compile time. You should be able to to look at any block of code at any time and be able to produce the list of packages required to make it run. Strawman proposal 2: Modify the import syntax to allow package identifiers: import qualified HaXML HaXML.XML.Parse import HAppS HAppS.ACID import Personal MyLib Define a packages file format to resolve package ids to locations: <packages> <package id="HaXML" src="http://haskell.org/HaXML/HaXML.hkg"> <remap ref="HUnit" src="http://haskell.org/HUnit2"/> <remap ref="Parse" src="#Parse"/> </package> <package id="Parse" src="http://parser.org/parse.hkg"/> <package id="HAppS" src="http://haskell.org/HAppS.hkg" /> <package id="Personal" src="../MyLibs" /> <redirect from="http://oldversion" to="http://newversion" /> </packages> Add a -p option to the compiler pointing to a packages file and use the content of that file to resolve module ids to implementations. The compiler MUST give an error if the user tries to associate the same module id with two different implementations [no grafting/module relativity!] Remove the -i compiler option. Any import of a module not in the local path must have a package id. [Get rid of import path order/overlap ambiguity!] Replace Cabal's Build-Depends field label with a Packages field label that takes a path to a packages file as a value. Add option to include a copy of all packages used by the current package. Give error if modules from other packages give conflicting module implementations. Allow user to resolve conflict in imported package files by using remap and redirect elements in the packages file.
I don't think it's necessary to specify dependencies with module granularity. This just increases the number of possible error cases, without adding functionality.
If I use multiple packages that export the same module identifier, I need a way to specify which one I want to use. Haskell's existing packaging model doesn't let met do that easily.
- Package dependencies in Build-Depends could be specified using URLs.
But then dependencies aren't checked at compile time and you can't specify which modules come from which packages.
- Cabal could download, build, and install dependencies without any user intervention.
Download and build? Great! Install? No thank you! In a fundamental sense, *installation* of third party libraries is exactly what I am opposing here. Library installation is what allows untracked dependencies to creep in. Users of executables definitely want a process for installation of executables in their local environment because they need a way to adjudicate potential conflicts between them (e.g. file associations). However, what users of libraries want is just a safe and easy way to populate a local cache of module-implementations from various sources and that is what I am asking for here. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
participants (2)
-
S. Alexander Jacobson -
Simon Marlow