[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] Distributed egg repo proposal
From: |
Imran Rafique |
Subject: |
Re: [Chicken-hackers] Distributed egg repo proposal |
Date: |
Fri, 18 Mar 2011 08:59:55 +0000 |
>> Imran said:
>> chicken-install first looks in *local-pkgs* and then *pkgs* to see if
>> my-wonderful-egg-2.0.tgz exists. If it doesn't, then chicken-install
>> looks upstream (from upstream-pkgs). If chicken-install had to fetch
>> something from upstream-pkgs, then this is automatically copied to
>> *local-pkgs*. This gives rise to a number of possibilities:
>
> Felix said:
> How can we be sure the system where the egg is to be installed
> has tar/gunzip? (a pure mingw32 build doesn't have this).
Good point.
('ci' = 'chicken-install')
ci is used in 2 different contexts:
1. To populate a tree. Use `ci --fetch-only` on a range of eggs, to
grab the upstream files, and populate *local-pkgs*. This would be how
the global tree maintainers ensure that *pkg* is populated (as
described in my first mail).
In this context, our ci tool is dependent upon certain local
infrastructure being present. If we want to be able to pull from an
upstream git repo (fetch-from-git), then we need git installed.
Similarly with other VCS's we're supporting pulling from. Same with
tar, and any other archive formats we want to allow egg authors to
submit their work in.
2. To install eggs. By regular users, on their machines, on different
architectures. Where we're making no assumptions on whats available
locally.
Well, in this instance, no matter what instructions the recipe file
contains, we're assuming that the global *pkgs* already has the stuff.
ci looks there first. (no outside deps once *pkgs* has been seeded, as
explained in the first mail)
So, no matter what type of archive/source tree we obtained in
context (1), ci is free to write the cached copy of that content (in
*local-pkgs*) in our own format. And in this context (2), thats the
format ci is going to use.
The only assumption we're going to make about the host system is
that we have the base chicken-scheme distribution already installed
and available. So our archive format is something which we can easily
unpack just using the tools the base distribution provides.
--
Regards,
Imran Rafique
- Re: [Chicken-hackers] Distributed egg repo proposal, (continued)
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/15
- Re: [Chicken-hackers] Distributed egg repo proposal, Jim Ursetto, 2011/03/15
- Re: [Chicken-hackers] Distributed egg repo proposal, John Gabriele, 2011/03/15
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/15
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/17
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/17
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Felix, 2011/03/17
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal,
Imran Rafique <=
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, John Cowan, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Stephen Eilert, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Imran Rafique, 2011/03/18
- Re: [Chicken-hackers] Distributed egg repo proposal, Peter Bex, 2011/03/18