Stop untracked dependencies!
S. Alexander Jacobson
alex at alexjacobson.com
Fri Apr 1 14:31:00 EST 2005
If we are in agreement about the overall goal, then I'll move on to
the specific issues that need addressing:
* We Need Free Packaging
Anyone should be able to create a package at any time for use in their
projects without having having to negotiate with any particular
centralized authority or community.
HTTP URLs have this property. The current package namespace does not.
Malcolm says "think wiki." I say: think world wide web.
* Free Packaging Means We To Handle Collisions in Module Namespace
Anyone should be able to use any combination of packages they want in
any of their programs at any time without worrying about whether those
packages export the same module name.
> We don't allow programs to contain two modules with the same name, for
> good reasons.
I'm not asking for that. I am totally ok with each module name
mapping to one and only one implementation per program. I just want
to be able choose that implementation even when my program uses two
packages that both happen to export the same module name.
* We Need to Associate Module Names with Specific Packages
In associating module names with particular packages, the design
choices come down to:
a. using a "Modules" file that maps module names to package ids/URLs
b. allowing package ids/URLs in import statements
c. allowing package *names* in import statement and using an
external "Packages" file to map package
names to package ids/URLs.
You could extend Cabal to implement (a). I just think (a) is really
annoying because it forces you to edit an external packages file every
time you do an import.
I prefer (c) because it does not have this problem and import
statements and remains very readable while instantly communicating the
dependency being created.
* Default Exposed Packages Are Untenable
Although, I agree that fussing with a -packages command line is
annoying, the need to associate module names with packages ids
makes the existing default exposed package compromise untenable.
But, all is not lost! If you choose (c) above, nothing stops you from
having a default global "Packages" file. Then your marginal work is
just to supply a package name in your import statements e.g.:
import HaXML HaXML.XML.Parse
And this doesn't seem so bad. And, the big bonus here is that the
default case of using Cabal gets much simpler because it can extract
the package names from your code and then automatically include
the relevant subset of the global packages file in your code. No more
need to produce a "build-depends" line manualy and no more risk of
getting it wrong!
You get an even bigger bonus if the package format has a standard
content-type because then Cabal can offer the packaging user the
option of including the dependent packages in the code itself so the
user doesn't have to worry about the recipient not having access to
the Internet, etc.
* In Any Case, Default Exposed Packages Are Also a Poor Compromise.
I don't want to have to worry about accumulating untracked dependcies
when I am doing quickie work with GHCi. I want my dependencies
checked every step of the way and should not have to round trip
through a Cabal packaging step just to verify them. Adding
-fhide-all-packages without doing (c) above does not solve this
problem. It just means that I keep having to restart GHCi with a
different command line every time I change a dependency OR I can keep
GHCi open and lose track of which packages I have added interactively
or just lose track of which packages are still necessary. In any
case, (c) with a default packages file is nearly as simple and MUCH
* Conclusion: Freedom is good.
At the top level, the choices comes down to these tradeoffs:
1. accepting some form of bureaucratic centralized control of
package and module name space in exchange for the putative
convenience of having default exposed packages and increasing the
risk of untracked dependencies.
2. reduing the risk of untracked dependencies and gaining freedom
from centralized control in exchange for acceptings some
responsibility for specifying which packages you want to use.
I weigh the risk of untracked dependencies highly and think the
marginal cost to the user of supplying package names in import
statements is minimal so I strongly prefer (2) and (c).
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
More information about the Libraries