Doru,
That is a good idea. It might also make sense from a Pharo perspective to have
a global fallback defined. I am expecting that the mechanisms that we come up
with will be useful for individual projects as well as Pharo overall, so
building in flexibility at load time (instead of embedded in the configuration)
is a good idea.
To summarize my takeaway on this issue:
- A pharo backup or secondary repository is a good solution to ensure
that configurations and packages are "guaranteed" to survive over long
periods
of time regardless of the state of the primary project repositories
- The secondary repository will be maintained by running a scraper script
that
scans the Metacello configurations that are critical to Pharo.
- The script will copy the packages referenced by the configurations into the
secondary repository. The configurations will also be copied into the
repository.
- Whether or not the configuration copies are modified to reference the
secondary
repository directly or not is still undefined.
- This issue will be managed as a separate collection of packages to keep the
core
of Metacello clean.
- The initial short term goal will be to provide a mechanism to do a
"one-shot"
checkpoint of configurations and packages (no configuration modification) so
that a Pharo 1.0 repository of all of the important build artifacts can be
archived in the event that the longer term goals aren't met in time. This
initial short term goal will be based upon code already in use at GemStone
to
perform a similar function.
- The second phase will be to work out the details of using the repository in
real life conditions ... and at this point there are a number of
possibilities
under consideration.
- More details when we get this far:)
If I've missed something important, I'm sure you'll let me know:)
Dale
----- "Tudor Girba" <[email protected]> wrote:
| Hi Dale,
|
| I believe the original problem is that you do not know upfront about
|
| where the actual files will be. In this case, perhaps the easiest
| solution is to provide some scripting facility to provide a repository
|
| mapping that should could be modified at loading time, and not be
| stored in the actual configuration.
|
| Suppose you have something like this:
|
| ConfigurationOfXXX>>baselineX: spec
| <version: 'X-baseline'>
| spec package: 'SomePackage' with: [ spec repository: 'SOME_URL' ].
| ...
|
| ConfigurationOfXXX>>versionX: spec
| <version: 'X' imports: #('X-baseline')>
| spec package: 'SomePackage' with: 'SomePackage.tg.1'.
| ...
|
|
| Maybe a solution would be that when loading you could say:
|
| (ConfigurationOfXXX project version: 'X')
| withRepositoryMapping: 'SOME_URL' -> 'SOME_NEW_URL';
| withRepositoryMapping: '...' -> '...';
| load
|
| What do you think?
|
| In this way, the original configuration specifies everything, and the
|
| URL works either as the actual URL or as an alias that can be mapped
|
| to something else later on when you know the actual URL. Actually,
| this can already be accomplished at engine level. I believe a simple
|
| scripting like above would just make it practical. What do you think?
|
| Cheers,
| Doru
|
|
| On 23 Feb 2010, at 21:18, Dale Henrichs wrote:
|
| >
| > ----- "Lukas Renggli" <[email protected]> wrote:
| >
| > | > Perhaps Gofer can be provided with a secondary repository
| location
| > | in the case when the primary repository fails.
| > |
| > | Yes, it can. You just specify multiple repositories and it will
| use
| > | them all. If you tell Gofer to #disableRepositoryErrors then it
| will
| > | silently ignore repositories that are not available.
| >
| > Lukas,
| >
| > The only thing that worries about including such repository all of
|
| > the time, is the cost of building the cache of repository when
| > resolving repositories ... the secondary repository would get pretty
|
| > large over time and most of the time (only in the case of errors)
| > would it need to be scanned.
| >
| > I suppose Metacello could handle load errors in the code that calls
|
| > Gofer and do a retry using the secondary repository...the secondary
|
| > repository _could_ be specified as part of the configuration, so
| > this probably isn't a bad idea...
| >
| > Thanks,
| >
| > Dale
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [email protected]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| --
| www.tudorgirba.com
|
| "Every thing has its own flow."
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
