On 22 August 2012 19:33, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | | Sorry, I wasn't clear - I meant precisely that it wasn't a Metacello | ConfigurationOf's responsibility to find something, but just to name | parts. _My particular_ setup might say "try local cache, then SS, | then | LatAm, and bail otherwise" while someone else's might say "try only | this special local network repo". In either case, I'd imagine | something like a configuration script supplying repository info to | Metacello. Metacello would simply say "I know about these repos, and | I'll try them in order." (This is just what Maven does. Not that I | think that Maven's necessary the ultimate tool: it works, and copying | things that work seems like a good plan.)
Frank,
You can already do this in your configuration by supplying a list of repositories instead of a single repository:
spec repository: 'http://seaside.gemstone.com/ss/metacello'; repository: 'http://www.squeaksource.com/metacello'.
Gofer is used to do the loads in Metacello, so I don't think that Gofer necessarily processes repositories in order , but this is the technique I use to insulate Metacello loads from repository outages...
Sure, but I can't do that for ConfigurationOfFFI, for example. I can't do that for ObjectsAsMethodWrappers, to talk about what's currently causing our builds to fail.
My latam hack for travis ci had to do with compensating for configurations that are "single sourced"...
Sure, and the presence of the latam mirror _ought_ to mean that any single-sourced thing on SS would no longer be single source. Surely it would be easier all round if travisCI.st (if I remember the name correctly) defined where to find these packages? (I can hear Chris & Chris saying "it should look on SM") I'll see if I can't hack up something we can pick over. frank
Dale