Isaac, I want to allow the user to know exactly which implementations they are using when they import a module-id while at the same time giving them maximal choice of implementations to use. Everything else here is just details. On Thu, 31 Mar 2005, Isaac Jones wrote:
What does this example have to do with untracked dependencies? Sounds like more of a problem with a lack of a central database ala Hackage.
* Oh, Network.HTTP is non-standard!? Thats wierd.
Someone installed Network.HTTP is installed as an "exposed package." Exposed packages are an obvious source of untracked dependencies as you agreed in the other thread. They should be prohibited.
* Uh Oh. Google reveals at least three different implementations... * Now, how do I determine which one is installed here?
Silence on which implementation are actually used creates a second untracked dependency. The implicit point here is that Cabal does not guarantee a mapping from a module identifier to a particular implementation. And even if you specify a build-depends, Cabal still does not provide any guarantees about the integrity of package namespace. Requiring that packages be listed in some centralized database may help, but it seems like the worst form of bureacracy. How does code get into the database? Who controls package namespace? What if I don't want to share all my code with the operators of the hackage server? Who is allowed to modify packages on the hackage server? And, if there is more than one hackage database/server, then we don't have a centralized database anymore.
* Is there a local copy of the package somewhere?
Does Cabal guarantee that you can easily reproduce a portable package from the stuff that is installed on the local machine? Or does it make it easy for the original package to be destroyed. As soon as you've destroyed the original package, you've created another untracked dependency.
* No? Ok, is it available for download somewhere? * Uhm, is the version I am using still available for download?
And if you don't have the original URL from which you retrieved it you have another untracked dependency. Also, does Cabal/Hackage provide a mechanism to give you notice if the official version of the package has changed and allow you to decide whether to update or not? If you use HTTP URLs rather than a new package namespace, then can use get HTTP's caching semantics to give you this update model for free.
* Oh, we made local changes too!? What were they?
Does Cabal/Hackage notify the user of differences between official packages and local versions? If not, this is another untracked dependency.
* 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...]
Does Cabal presume that all packages are guaranteed to be available based on the name in build-depends or does it provide an option to ship them from a machine with a local copy? If you don't have the later, then you have another risk in your code.
* But what happens if I don't have root/admin on the target machine? [...] * Oh, this package conflicts with something already installed? [etc.]
Are some packages allowed to modify the haskell implementation itself? More risk of untracked dependencies.
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.
Actually, it gets checked at build time if you use cabal to build during development. This can fail for (ghc-pkg) exposed packages, though, see the message I just posted.
I don't know what "build time" means here. I want them checked when I am playing with my code interactively using ghci. And I need a way to resolve potential conflicts in the dependencies of packages I am using. See the remap and redirect tags from packages file format in my proposal.
Strawman proposal 2:
Modify the import syntax to allow package identifiers:
import qualified HaXML HaXML.XML.Parse import HAppS HAppS.ACID import Personal MyLib
Can you relate this proposal to the previous grafting work?
The previous grafting work was about using the same module id from different implementations. Consistent with the community's rejection of grafting, this proposal explicitly requires that the compiler produce an error if the user attempts to use the same module id from two different implementations.
It sounds like you're basically just adding a new root to the module hierarchy.
No, I am just providing a way for the user to specify exactly which implementation should be used to provide the functionality identified by a given module id.
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.
Does the grafting proposal solve this problem?
It might, but grafting was rejected and this problem needs to be solved. Implementation of my proposal would solve the problem without requiring grafting. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com