Re: [Chicken-users] Experience of using Chicken in production environment

[felix winkelmann]

On Sat, Apr 11, 2009 at 4:34 AM, Aleksej Saushev <address@hidden> wrote:

>
> 1. Skipped release.
>
> Right at the start the Chicken project is close to 4.0 release, the last
> announced (stable) release is 3.4.0. At the same time, there exists
> 3.5.0 release, which is more recent stable release as per convention
> elaborated earlier, and even later releases from 3.5 series. 3.5.0 isn't
> announced and there's little information on what's going on.
>
> Thanks to close contacts with Chicken developers, I'm told that 3.5.0
> release has serious or critical bug that prevents its usage.
> I'm recommended to either stay with 3.4.0 (the most recent _announced_
> stable release) or update to one of "unstable" release from 3.5 branch.
> Given that, I'm going to follow conservative way and stay with 3.4.0.

Yes, that's the sensible thing to do. The 3.5.0 release story was
an unfortunate one. Development should have been frozen after it
was clear that 4.0.0 was going to be released soon. Well, it's too
late, and we can't do anything about it. But as 3.4.0 works and
*has* been announced you have a version that you can use as
a base for your development.

>
> 2. Unsupported stable branch.
>
> Meanwhile Chicken development continues and it's going to enter
> pre-release state. From the development list I learn that 4.0.0
> is really a major milestone, it does change things significantly
> and all auxilliary software (which is of primary importance to me)
> has to be _ported_. When asked about support plans for branch "3",
> maintainer answers that there's no interest. I have to assume that
> support is mostly discontinued(?).

Progress has to be made and the module system is a major
quantum leap that was direly necessary if all that auxilliary software
is still supposed to work in a few years when all those eggs will
get into serious name-conflicts (we already have them). I would also
like to point out that the eggs and the infrastructure to provide them
to users is fully working and will be kept that way for an undetermined
but lengthy time. And after all I think we do a pretty good job even
if something breaks from time to time. A wc on the svn repo should
demonstrate that, for the amount of code in there, we could do
worse.

The porting effort for most eggs will be trivial. Some eggs make no
sense with chicken4 ("modules", etc.) and some eggs are not worth
porting. The new installation tools have been rewritten largely to
make it easier for users to work with egg tree snapshots and so
achieve more stability, even in the presence of continuing maintenance.

> 3. Release cycle is too short?
>
> The development goes on, and we see 4.0.0 pre-release and release.
> But that's only the core, most of auxilliary software ("eggs") still
> has to be ported, and new release gets more support, which leaves stable
> branch, that has almost no support already, with even less support.

I can't really agree with that. We do whatever we can and our resources
are severely limited. Less than a handful of core-developers with varying
amount of time, a huge body of scheme
code and pretty active development. Sorry, we can't quite compare with
the gcc maintainers or the Apache foundation. And considering the
frantic evolution of chicken the system is remarkably robust.

>
> 4. What is it? What can I do with it??
>
> Target systems reside in separate network, there's no access to Internet,
> unless I setup connection via GSM modem. Thus I need to fetch all
> necessary files, bring them there, copy them on target systems and install.
> Obvious. Not so obvious, when you're doing it.
>
> First, you don't have recursive fetch. Workaround: install all what you
> need on development system, list extensions, _guess_ corresponding eggs'
> names, fetch those, bring them on the scene, and... get busted.
> You cannot pass neither distributed file name nor name of directory with
> downloaded files to "chicken-setup" tool. It simply doesn't support it.

The format of the .meta files in the repository practically screams out
for automatic processing. You could take an egg-tree and easily collect
all necessary information to roll your own deployment infrastructure.
Yes, you'll have to write it yourself, but you can not expect us to
take care of every possible deployment scenario. This is a subject
of ongoing research and we will improve the system as much as
we can. In the moment simplicity is (IMHO) the most important thing,
because it makes it easier for users to write their own custom
deployment code.

>
> Alright, I am wise enough to try it before I lose connection to supporters,
> who can tell that dowloaded files are gzipped tarballs and "chicken-setup"
> can be run from egg source directory to get the work done. Alright, all's
> well that ends well. Nevertheless writing script to do what could be done
> already is a bit annoying.

It's not perfect, I completely agree. But writing a bit of code to get the
deployment/installation you need gives you more control and will fit
your personal requirements better.

>
> 5. Where's it???
>
> I haven't run into this problem yet, but where's download cache or how
> can I turn it on?

Chicken 3 has no download cache. "chicken-setup" is not a full package
manager like "dpkg" and people should not expect it to be one.
Chicken-4 hasn't one either but can be used to provide something
comparable. Alternatively we can cram the egg-tools full of features that
fit nobody perfectly and are eternally bug-ridden.

>
> 6. Versioning, versioning...
>
> Previously I thought that having version number in file name is very
> useful, since it is really convenient. I was mistaken. Experience
> revealed that _not_ having versions is _very_inconvenient_.
>
> Especially when you know that an egg was fixed in last 15 minutes,
> and you're waiting for a new file.

If you are in a production situation doing this is very, well..., unsmart.
You should take a snapshot of the tree and use version control for this.

>
> 7. No comments.
>
> $ chicken-setup -d srfi-19
> *** output flushed ***
> $ csi
> *** output flushed ***
> #;1> (use srfi-19)
> *** output flushed ***
> #;2> (date->string (current-date))
> "Sun Nov 15 20:58:47-18761321 1987"
> #;3>
> $ date
> Sat Apr 11 06:20:11 MSD 2009
> $ uname -mrs
> FreeBSD 6.3-STABLE i386
>
> ??
>

Yeah, srfi-19 is an old friend. I hope I will never have to use it.

> Acknowledgements: I'm grateful to Peter Bex and Elf, who provided very
> much valuable support in my work, and Alaric Snell-Pym, without whose
> encouraging mentions I wouldn't even dare to use Chicken for this,
> and numerous others who provided so much material to have fun and grief.
>
> I'm still going to finish the project despite all the obstacles. Stay tuned.

Excellent. Good luck and please keep us up to date. I appreciate your
courage to use chicken in production work and hope that, despite the
problems you face (and which we all face daily, I guess), you'll
succeed in the end.


cheers,
felix