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

[Aleksej Saushev]

felix winkelmann <address@hidden> writes:

> On Sat, Apr 11, 2009 at 4:34 AM, Aleksej Saushev <address@hidden> wrote:
>>
>> 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.

There's one serious problem with this: there's no easy way to get
specific egg version that is known to work. And there's no way to
get it with "chicken-setup" tool. Since this is new feature for 3.4
series, it is unlikely to appear.

> 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.

I don't know what is "egg tree snapshot", but I have some doubts that
it is good decision to require users to have the whole source tree
locally. I may be wrong here, since I don't know what you mean exactly.

>> 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.

The biggest problem is the inability to use chicken-setup as pkg_add,
while this shouldn't be such a problem to implement on your side.
I hope this will be fixed in future in some way.

>> 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.

Well, there're some essential features, like "fetch" and "add/install",
it is sufficient to expose them in a more convenient way.

>> 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.

Check pkgsrc or FreeBSD ports, you don't need version control for it,
a set of tarballs is enough.


-- 
BECHA...
   CKOPO CE3OH...