cabal dependency on code repositories.
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 :)
On 19 December 2010 17:44, Greg Weber
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.
The first system I want to add is to allow cabal-install to install from tarballs identified by a URL, e.g. cabal install http://example.org/~me/foo-1.0.tar.gz As you know, .cabal files can specify source repos so in principle one could write a tool to install from a source repo. In practice there are a number of things to solve involving how you manage local caches of remote repos etc. The easiest thing to get working first is installing from tarball URLs, but I would welcome patches for the source repo feature, in particular a specific plan for how users interact with the system. Duncan
On Sun, Dec 19, 2010 at 5:01 PM, Duncan Coutts wrote: On 19 December 2010 17:44, Greg Weber 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. The first system I want to add is to allow cabal-install to install
from tarballs identified by a URL, e.g. cabal install http://example.org/~me/foo-1.0.tar.gz As you know, .cabal files can specify source repos so in principle one
could write a tool to install from a source repo. In practice there
are a number of things to solve involving how you manage local caches
of remote repos etc. The easiest thing to get working first is
installing from tarball URLs, but I would welcome patches for the
source repo feature, in particular a specific plan for how users
interact with the system. Duncan Being able to install a tarball is a great first step and would provide a
mechanism for taking care of some of the use cases.
In terms of specific user interaction plans for installing from a repo, I
would point again to ruby's Bundler as a starting point. Basically instead
of putting in a version number constraint one can put in a git url. That url
points to a repo with a gemspec (.cabal file) which has the version number.
It is important to note that Bundler operates and a project-focused manner.
Bundler also creates a file 'Gemfile.lock' which lists every package being
used for the project and its exact version. This helps when working in a
team or deploying- by checking in this file one can ensure that everyone
else (and the production server) is using the *exact* same versions of
packages. For library development it is not recommended to check in the lock
file. Changing the Gemfile (cabal file) and installing (cabal configure)
will update the lock file.
This functionality is similar to the tool capri in some ways, but instead of
having a project private package set it just has a lockfile that specifies
exact versions. I think haskell may require a project private repo because
it compiles packages instead of interpreting them. For a project private
package set in Ruby there is a tool called RVM which has a feature called
'gemsets'. The main purpose of RVM though, is actually to be able to easily
switch between multiple versions of Ruby (and it does this amazingly well by
operating at the shell level).
I am rambling now, but the end user interaction is essentially just editing
the Cabal file with the proper git url and re-compiling. The releaser does
not have to do anything either- they don't even have to change the version
number in the cabal file. Ruby Gems and Bundler use the git hash of the repo
as the version number. However, Bundler still knows the package version
number for dependency resolution.
Greg Weber
participants (2)
-
Duncan Coutts -
Greg Weber