Stop untracked dependencies!

Isaac Jones ijones at
Thu Mar 31 17:28:04 EST 2005

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

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
>>     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!

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 mailing list