chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] Taming the egg versioning wilderness


From: Mario Domenech Goulart
Subject: Re: [Chicken-hackers] Taming the egg versioning wilderness
Date: Mon, 25 Feb 2013 09:16:59 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Hi der gute Moritz,

On Mon, 25 Feb 2013 09:51:22 +0100 Moritz Heidkamp <address@hidden> wrote:

> I just had the following problem (again): I tagged a new version of the
> lowdown egg (0.0.6). While doing so I realized that the previous tag
> (0.0.5) still installed itself as 0.0.4 via the install-extension
> invocation in its .setup file. This lead me to think over the whole
> situation of how we deal with egg versioning and I found it pretty
> error-prone and inconvenient for both users and authors. Sticking to my
> example:
>
> 1) Users get confused because if they run chicken-install lowdown (or
>    even chicken-install lowdown:0.0.5), chicken-status will afterwards
>    tell them that 0.0.4 is installed in this case.
>
> 2) Authors have to be vigilant to always keep three places in sync: The
>    version in the .setup file (another issue here is that each
>    invocation of install-extension and install-program require the
>    version to be passed -- hopefully it's always the same one), the
>    version in the .release-info file and (if a VCS is used, which is
>    usually the case) the version in the tag name.
>
> It may of course be that I misunderstand some intentions of the
> versioning system as it is (e.g. why it is possible to install multiple
> extensions and programs with differing versions from within an egg which
> itself can have yet another differing version). If that's the case I'd
> be happy to be enlightened about it!
>
> Otherwise I'd suggest to somehow get rid of at least the versions in the
> .setup file. Maybe it would be possible to make them optional and use
> the egg's version as a default in this case?
>
> Let me know what your thoughts are on this issue. I am happy to try to
> come up with a patch should we agree on how to proceed.

I don't know exactly how to simplify this situation, so I'll comment on
how detect those errors.

Salmonella is able to detect those kind of errors if run with the
--eggs-source-dir option.  In that case, it uses chicken-install with
the local transport.  tests-call-cc.org doesn't use that mode, so it is
unable to detect those errors.  Even if it used the local transport, it
would detect the error only after it was published.  It would be
slightly better than the current situation, but using the local
transport would mean not testing the network part of chicken-install and
the server-side part (henrietta servers) -- we caught some problems
related to those parts in the past.  Besides that, using
--eggs-source-dir is not compatible with salmonella-epidemy, since
chicken-install uses the eggs source directory to compile code, which
makes it subject to race conditions when running multiple salmonella
instances in parallel (that's what salmonella-epidemy does).  We current
don't use salmonella-epidemy on tests.call-cc.org, but as soon as we get
a better machine we can use it.

Salmonella in the egg-lint mode could catch the version problem before
the egg is published, but setting it up to do that is a bit awkward:
you'd need to "fake" the directory layout expected by chicken-install in
the local transport mode (<egg>/tags/<version>), and you'd need to
provide --eggs-source-dir.  I don't think it is practical.  After you do
all that, you probably realized that you have a version problem.

We could make salmonella check versions even in the non local transport
mode: it could query henrietta for the egg versions, pick the latest and
then proceed to install/test the egg.  Then it could check if the
version stored in .setup-info matches the latest version provided by
henrietta.  But, again, it would only report the problem ater it has
been published.  Also, since the
pick-latest-version/install/check-installed-version steps are not
atomic, salmonella could report some false problems.

With regard to the problem of a single egg installing multiple extension
versions, salmonella could detect that for newer chickens (IIRC,
chickens > 4.7.0 -- not sure about the exact version), since they add
the the egg-name field to .setup-info files.  So, salmonella could read
all the .setup-info files in the local egg repository, find the ones
that have egg-name corresponding to the egg under test and check if the
versions are the same.

Best wishes,
Mario
-- 
http://parenteses.org/mario



reply via email to

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