[Chicken-users] ANN: Test version of new egg release system available

[Peter Bex]

Hello everyone,

I am pleased to announce that an evaluation version of the distributed
system for egg release management has now been implemented.  This was
done during the Chicken hacking weekend in Cologne, and thanks to the
further efforts of Mario and Moritz this week, the system can now be
taken for a test run.  Please note that we are *not* committed to
switch to this system at this point: We are just trying out to see how
it works for our community, and if there are strong objections it can
still be dropped.

For those who didn't follow the earlier discussions about this system,
I'll try to explain how it works.  You can find a more detailed
explanation at http://wiki.call-cc.org/distributed-egg-repos

Basically the idea is that you can now host your eggs wherever you
prefer. This should make it easier for people to contribute eggs.  For
those who dig git, you can now use Github to host your eggs.  Those
who prefer mercurial can use Bitbucket.  Even if you decide to write
your very own version control tool and host it on your own personal
server, you can still use that for developing your Chicken eggs.
That's because the system is actually VCS-agnostic; everything is
based purely on plain HTTP. Eggs are fetched either as tarballs, zip
archives or separate files.

Don't be afraid if you liked everything just the way it was, though!
Chicken egg hosting in subversion is still supported and will continue
to be supported.  There's also very little change in workflow.  There
are two small things you need to remember when developing an egg:

- There's now a new file called "EGGNAME.release-info".  This file tells
   the new system what releases are available, and how to obtain these.
   This file needs to be linked once in a central list of available eggs
   when you first create a new egg (described below).
- The "EGGNAME.meta"-file must now contain a list of files that should be
   present in a full download of the egg.  This step is only required
   when you're using a code hosting method that doesn't offer a way to
   serve up release tarballs, though!  This is currently the case for the
   Chicken eggs subversion tree.

A cronjob on call-cc.org will automatically fetch all new releases
that it finds, so that people can download them using "chicken-install"
without requiring them to have all those different VCS tools installed.

I've written up a tutorial on how to release eggs under the new system:
http://wiki.call-cc.org/releasing-your-egg

There are still a few rough spots; it would be nice if releasing an
egg would be more automated (with a shellscript, for example), so you
don't need to manually maintain the meta-file and release-info file.
This will be worked on during the rest of this week.  It would also
be nice if people who are using other VCSes would take a look at the
system and add descriptions how to use these VCSes with this system.

We've already gone ahead and updated everyone's eggs so that the
existing eggs still work with the new system without hassle.  Only
for new eggs or new releases do people actually need to do anything
extra.

For those who would like to test the new system, you can use the
following on your commandline:

chicken-install -l code.call-cc.org/cgi-bin/henrietta-cache.cgi kalaha

This installs the egg "kalaha", which is a small game Moritz wrote.
It's an egg that's _only_ available through the new system which we
used to verify it actually works.  It has two dependencies which are
taken from the subversion tree, to prove that this also still works as
before.

To get an idea of how this works, have a look at Kalaha.
Its release-info file is linked in the master list, here:
http://bugs.call-cc.org/browser/release/4/egg-locations
There we can see it's hosted on Github in the line

  (kalaha 
"https://github.com/DerGuteMoritz/kalaha/raw/master/kalaha.release-info";)

The release-info file declares the available releases
(currently only "0.1"), which can be fetched as a tarball by
substituting the egg's name and release version in the supplied URI,
giving us https://github.com/DerGuteMoritz/kalaha/tarball/0.1
which is indeed a tarball.  This is cached on the call-cc server
by henrietta-cache, the only new component in this whole scheme.
Henrietta-cache is hosted at Bitbucket; you can get it at
https://bitbucket.org/sjamaan/henrietta-cache
Try to figure out how this was set up; it's analogous to how
it works at Github. :)

So, please give it a try and let us know how it works for you!

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth