chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] new setup tools


From: felix winkelmann
Subject: [Chicken-users] new setup tools
Date: Fri, 22 Aug 2008 13:43:04 +0200

Hello!


The hygienic branch now features a nearly complete rewrite of
"chicken-setup". The new setup tools can be built optionally,
by passing "BUILD_SETUP_TOOLS=1" when invoking "make"
and "make install" (otherwise the normal "chicken-setup" is built and
installed).

The new system has been heavily simplified but should be backwards
compatible from the point of view of .setup scripts. Functionality has
been grouped into modules to allow more re-use and possibly creating
other, alternative extension tools (this means that one has to have a
working hygienic chicken to compile the tools, the recommended
way is to build normal, install and then build and install again with
BUILD_SETUP_TOOLS=1).

The new tools are:

chicken-install - downloads and installs eggs
chicken-uninstall - guess
chicken-status - lists installed modules or files

Modules that are installed together with the base system are
setup-download, setup-utils and setup-api. The .setup script
is now just invoked via "csi" and has access to the usual
setup functionality, provided in the setup-api module.

Documentation is currently only available in man pages, the wiki-syntax
manual will be updated soon. But it would be nice, if people could
actually test it a little, since the new system has several
advantages over the old one:

- extension-sources can be retrieved from the local filesystem,
  via a svn checkout or over http with full dependency and version
  checks.
- When installing from the local filesystem (which should in that case
follow the usual layout of
  a release branch), eggs are built directly inside the tree.
- Installing from svn checks out an egg directly from an egg repo into
  a temporary directory.
- Installing over http fetches the files over a custom protocol that is served
  by "henrietta", a CGI that performs a local svn query/checkout and transmits
  the files uncompressed (sic - that way the client doesn't have to have tar/gz
  installed).
- "henrietta" uses the same transport selection as chicken-install and thus can
  serve eggs from svn, the local filesystem or even http (whether this
makes sense
  is a different question).
- The CGI is installed on galinha right now and accesses our svn repository
  directly. So no more waiting for egg-post-commit (In other words,
the eggs henrietta lays
  are not always golden but guaranteed to be fresh...).
- Installation allows specifying a particular version, if desired. Dependencies
  in .meta files are taken into account and can optionally define dependencies
  with a specific version ("(needs X Y Z)" -> "(depends (X 1.2.0) (Y
1.0.0) Z)");
  if no version is given, the newest will be installed. This should
work with the
  usual tagging scheme, but hasn't been tested that much, since the release/4
  branch doesn't provide many (any?) tagged eggs, yet.
- When "chicken-install" is invoked with the "-test" option, optional
test-specific
  dependencies are installed as well (meta property: "(test-depends X ...)").
- The code base has been cleaned up heavily and uses modules. The tools
  don't provide many options and should be easy to use.
- Support for other VCSes can be easily added, once a suitable mapping for
  eggs and their versions can be found. Subversion allows some flexibility here,
  I don't know how this should be done for, say, git, hg, mtn or cvs (feedback
  welcome).
- Since installation from a local filesystem is possible, which
includes version-checks
  and dependency tracking, deployment of code in source form can now
  run chicken-install on a sub-tree in the sources and thus allows installing
  application-specific extensions cleanly.

Once this works reliably, the old setup will be thrown away. It's is likely that
I have forgotten things or didn't take certain scenarios into account. The tools
are quite promiscuous in their debug-output, but lots of obscure progress info
including strange techno-jargon always looks cool and makes it clear
what happens,
and simplifies the debugging.

Feedback and patches are appreciated.


cheers,
felix




reply via email to

[Prev in Thread] Current Thread [Next in Thread]