Stop untracked dependencies!
S. Alexander Jacobson
alex at alexjacobson.com
Fri Apr 1 01:31:01 EST 2005
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
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
>> * 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
>> * 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
>> 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
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Libraries