Stop untracked dependencies!
ijones at syntaxpolice.org
Thu Mar 31 17:28:04 EST 2005
"S. Alexander Jacobson" <alex at alexjacobson.com> writes:
> 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.]
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.
>> 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
> 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.
> 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? It sounds
like you're basically just adding a new root to the module hierarchy.
My $0.02: I'm still more comfortable with solving this outside the
core language, with the package system, cabal, and hackage.
>> 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?
>> - Package dependencies in Build-Depends could be specified using
> 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!
FWIW, right now (thanks to Lemmih), Hackage has a client-server
interface so that the client can query hackage as to the dependencies
for a given package, and the URLs. So you'll be able to "caball-get
foo" and it'll download and install foo's dependencies along with foo.
Since it'll be source-packages only (at least at first), there's no
"cabal-get build-dependencies-of foo", since to use foo you'll need
the build and run-time dependencies.
More information about the Libraries