[Haskell-cafe] cabal dependency on code repositories.

Greg Weber greg at gregweber.info
Sun Dec 19 18:44:32 CET 2010


Michael Snoyman and I were discussing the need for beta releases of Yesod
and he encourage me to post this to the cafe. Beta releases could be built
into the hackage system. However, this can be viewed as a more general
problem of distributing multiple versions of code (stable vs. experimental,
forks, etc). This is a problem that has been largely solved by version
control, but in this instance just needs some integration with an installer
system.

In the ruby world there is a tool called bundler that is now the standard
installer- basically bundler combined with rubygems it is like cabal
combined with hackage. In addition to referencing a published library
version, with bundler one can reference a git repository, and even reference
a particular branch or revision. Essentially with beta releases you are
trying to release multiple branches of your repository. This is also very
useful for dealing with multiple forks of a package. If I have problems with
a package I can look at the github repo and look for forks with bug fixes,
and then point the Gemfile (cabal file) to that repo. The repo must have a
gemspec (cabal file).

Essentially this removes the step of the code writer of needing to edit the
cabal file or publish to hackage. This is good because many code writers do
not want to publish their minor variations of packages on hackage or do not
want to publish new packages that they feel are of low quality. This is also
good from the perspective of the code user- I normally don't want to see
minor variations on hackage. If I am interested in minor variations I will
go to the github repo and look at the different branches and forks where it
will be clear to me what the difference is- it would be difficult to
accurately portray this information on hackage.

Productivity in modern programming is largely about code re-use, and I only
see this as becoming more important. Type safety and Cabal do a great job
facilitating code re-use. I think we can make cabal even more useful here.
Has this ability been discussed before for cabal? t would be great if it
could at least be worked on for the next Google Summer of Code.

Sorry if I offended anyone by exclusively mentioning git, but that is the
only version control system used by Rubyists :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20101219/33a84d8e/attachment.htm>


More information about the Haskell-Cafe mailing list