[Pharo-project] latam mirror down?
On 21 August 2012 22:20, Dale Henrichs <dhenrich@vmware.com> wrote:
http://www.dsal.cl/squeaksource/
http://www.downforeveryoneorjustme.com/http://www.dsal.cl/squeaksource/
It's down for me too. I'm assuming it's your Travis builds failing like mine are. One option that occurs to me is to convert ObjectsAsMethodsWrapper to filetree and store a copy on GitHub? GitHub have rather more resources to through at availability than we do, so we might as well take advantage. frank
Yes, it's the travis builds ... It's more than ObjectsAsMethodsWrapper, because once the mirror is installed all squeaksource requests are routed to the mirror, so failing to load ObjectsAsMethodsWrapper is not the only issue. I am unconditionally using the mirror in the Travis images... I will now have to make a flag in the builder to allow one to choose whether to use the mirror or not ... that way when squeaksource flakes out you can use the mirror (assuming the mirror is resurrected ... it's been down for days) and use squeaksource when it is available ... Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 12:54:15 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 21 August 2012 22:20, Dale Henrichs <dhenrich@vmware.com> wrote: | > http://www.dsal.cl/squeaksource/ | > | > http://www.downforeveryoneorjustme.com/http://www.dsal.cl/squeaksource/ | | It's down for me too. I'm assuming it's your Travis builds failing | like mine are. One option that occurs to me is to convert | ObjectsAsMethodsWrapper to filetree and store a copy on GitHub? | GitHub | have rather more resources to through at availability than we do, so | we might as well take advantage. | | frank | |
On 22 August 2012 15:16, Dale Henrichs <dhenrich@vmware.com> wrote:
Yes, it's the travis builds ... It's more than ObjectsAsMethodsWrapper, because once the mirror is installed all squeaksource requests are routed to the mirror, so failing to load ObjectsAsMethodsWrapper is not the only issue.
I am unconditionally using the mirror in the Travis images...
I will now have to make a flag in the builder to allow one to choose whether to use the mirror or not ... that way when squeaksource flakes out you can use the mirror (assuming the mirror is resurrected ... it's been down for days) and use squeaksource when it is available ...
Isn't a flag more complicated than a fall-over? In other words, try SS, fail, use LatAm (or vice versa). My hacks for ConfigurationOfControl class >> bootstrapPackage:from: did this, and I'd like to think they don't completely suck. Otherwise your build fails and you have to edit its invocation to get it to work, by which time source A has disappeared and source B's back up, so you unflick the flag and ... There's a thought half-formed in my head. It's something like this: a configuration says "I'm built out of parts called foo, bar and baz. Where they come from I don't care." Something else (by default, at least) does the searching, trying various well-known configurations. Er, I guess something a bit like Maven's repository mirrors: http://maven.apache.org/guides/mini/guide-mirror-settings.html. But that's more of a long term solution, and not something you'd want to get into just before ESUG. frank
Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 12:54:15 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 21 August 2012 22:20, Dale Henrichs <dhenrich@vmware.com> wrote: | > http://www.dsal.cl/squeaksource/ | > | > http://www.downforeveryoneorjustme.com/http://www.dsal.cl/squeaksource/ | | It's down for me too. I'm assuming it's your Travis builds failing | like mine are. One option that occurs to me is to convert | ObjectsAsMethodsWrapper to filetree and store a copy on GitHub? | GitHub | have rather more resources to through at availability than we do, so | we might as well take advantage. | | frank | |
Frank, The rationale for turning on the latam mirror was driven by metacello bootstrapping concerns (metacello is bootstrapped from squeaksource/gemsource so isn't sensitive to squeaksource being down) but the desire to use the latam mirror for other configs that may be loaded like omnibrowser, profstef, etc.... those were the issues I was running into when squeaksource was down for several days and I was trying to get work done ... I just threw the switch to the latam mirror and didn't have to worry about it until now... If squeaksource decides to go down now, there is no latam mirror and that is a real problem! There are configuration level things that folks can do like providing two repositories in the specification, but not everyone does that and I'm not sure that the logic for trying different schemes for supplying the schemes is a Metacello responsibility ... I liked the latam solution because it is a developer decision to switch repositories, not a default action by Metacello when it "thinks" that a repository is down and switches to another repository without the developer being aware of what's going on ... In the large I agree that solutions are needed, but I'm not convinced that Metacello is the right place to manage these choices (especially given the fact that you can specify mulitiple repositories in a configuration so that you can explicitly define the primary, secondary, tertiarty, etc. repository). Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 8:02:31 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 15:16, Dale Henrichs <dhenrich@vmware.com> wrote: | > Yes, it's the travis builds ... It's more than | > ObjectsAsMethodsWrapper, because once the mirror is installed all | > squeaksource requests are routed to the mirror, so failing to load | > ObjectsAsMethodsWrapper is not the only issue. | > | > I am unconditionally using the mirror in the Travis images... | > | > I will now have to make a flag in the builder to allow one to | > choose whether to use the mirror or not ... that way when | > squeaksource flakes out you can use the mirror (assuming the | > mirror is resurrected ... it's been down for days) and use | > squeaksource when it is available ... | | Isn't a flag more complicated than a fall-over? In other words, try | SS, fail, use LatAm (or vice versa). My hacks for | ConfigurationOfControl class >> bootstrapPackage:from: did this, and | I'd like to think they don't completely suck. | | Otherwise your build fails and you have to edit its invocation to get | it to work, by which time source A has disappeared and source B's | back | up, so you unflick the flag and ... | | There's a thought half-formed in my head. It's something like this: a | configuration says "I'm built out of parts called foo, bar and baz. | Where they come from I don't care." Something else (by default, at | least) does the searching, trying various well-known configurations. | Er, I guess something a bit like Maven's repository mirrors: | http://maven.apache.org/guides/mini/guide-mirror-settings.html. | | But that's more of a long term solution, and not something you'd want | to get into just before ESUG. | | frank | | > Dale | > ----- Original Message ----- | > | From: "Frank Shearar" <frank.shearar@gmail.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Wednesday, August 22, 2012 12:54:15 AM | > | Subject: Re: [Pharo-project] latam mirror down? | > | | > | On 21 August 2012 22:20, Dale Henrichs <dhenrich@vmware.com> | > | wrote: | > | > http://www.dsal.cl/squeaksource/ | > | > | > | > http://www.downforeveryoneorjustme.com/http://www.dsal.cl/squeaksource/ | > | | > | It's down for me too. I'm assuming it's your Travis builds | > | failing | > | like mine are. One option that occurs to me is to convert | > | ObjectsAsMethodsWrapper to filetree and store a copy on GitHub? | > | GitHub | > | have rather more resources to through at availability than we do, | > | so | > | we might as well take advantage. | > | | > | frank | > | | > | | > | |
On 22 August 2012 18:30, Dale Henrichs <dhenrich@vmware.com> wrote:
Frank,
The rationale for turning on the latam mirror was driven by metacello bootstrapping concerns (metacello is bootstrapped from squeaksource/gemsource so isn't sensitive to squeaksource being down) but the desire to use the latam mirror for other configs that may be loaded like omnibrowser, profstef, etc.... those were the issues I was running into when squeaksource was down for several days and I was trying to get work done ... I just threw the switch to the latam mirror and didn't have to worry about it until now...
If squeaksource decides to go down now, there is no latam mirror and that is a real problem!
That is indeed a real problem, and something that hosting the whole world on github would ameliorate, but not solve.
There are configuration level things that folks can do like providing two repositories in the specification, but not everyone does that and I'm not sure that the logic for trying different schemes for supplying the schemes is a Metacello responsibility ... I liked the latam solution because it is a developer decision to switch repositories, not a default action by Metacello when it "thinks" that a repository is down and switches to another repository without the developer being aware of what's going on ...
In the large I agree that solutions are needed, but I'm not convinced that Metacello is the right place to manage these choices (especially given the fact that you can specify mulitiple repositories in a configuration so that you can explicitly define the primary, secondary, tertiarty, etc. repository).
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
Dale
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 8:02:31 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 15:16, Dale Henrichs <dhenrich@vmware.com> wrote: | > Yes, it's the travis builds ... It's more than | > ObjectsAsMethodsWrapper, because once the mirror is installed all | > squeaksource requests are routed to the mirror, so failing to load | > ObjectsAsMethodsWrapper is not the only issue. | > | > I am unconditionally using the mirror in the Travis images... | > | > I will now have to make a flag in the builder to allow one to | > choose whether to use the mirror or not ... that way when | > squeaksource flakes out you can use the mirror (assuming the | > mirror is resurrected ... it's been down for days) and use | > squeaksource when it is available ... | | Isn't a flag more complicated than a fall-over? In other words, try | SS, fail, use LatAm (or vice versa). My hacks for | ConfigurationOfControl class >> bootstrapPackage:from: did this, and | I'd like to think they don't completely suck. | | Otherwise your build fails and you have to edit its invocation to get | it to work, by which time source A has disappeared and source B's | back | up, so you unflick the flag and ... | | There's a thought half-formed in my head. It's something like this: a | configuration says "I'm built out of parts called foo, bar and baz. | Where they come from I don't care." Something else (by default, at | least) does the searching, trying various well-known configurations. | Er, I guess something a bit like Maven's repository mirrors: | http://maven.apache.org/guides/mini/guide-mirror-settings.html. | | But that's more of a long term solution, and not something you'd want | to get into just before ESUG. | | frank | | > Dale | > ----- Original Message ----- | > | From: "Frank Shearar" <frank.shearar@gmail.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Wednesday, August 22, 2012 12:54:15 AM | > | Subject: Re: [Pharo-project] latam mirror down? | > | | > | On 21 August 2012 22:20, Dale Henrichs <dhenrich@vmware.com> | > | wrote: | > | > http://www.dsal.cl/squeaksource/ | > | > | > | > http://www.downforeveryoneorjustme.com/http://www.dsal.cl/squeaksource/ | > | | > | It's down for me too. I'm assuming it's your Travis builds | > | failing | > | like mine are. One option that occurs to me is to convert | > | ObjectsAsMethodsWrapper to filetree and store a copy on GitHub? | > | GitHub | > | have rather more resources to through at availability than we do, | > | so | > | we might as well take advantage. | > | | > | frank | > | | > | | > | |
----- 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... My latam hack for travis ci had to do with compensating for configurations that are "single sourced"... Dale
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
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 11:56:12 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 19:33, Dale Henrichs <dhenrich@vmware.com> wrote: | > 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, If you're talking about what I did in builderCI ... then I agree wholeheartedly that a failover of some sort is called for when trying to bootstrap the latam mirror support ... squeaksource was dead at the time and I was in a hurry ... (haven't we heard that before) ... I'd welcome improvements there.... A fail-over scheme for FFI or any arbitrary projects (is that what you're getting at?) is a bit more difficult, but I'd definitely be interested in seeing what you're thinking ... Dale
On 22 August 2012 21:08, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 11:56:12 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 19:33, Dale Henrichs <dhenrich@vmware.com> wrote: | > 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,
If you're talking about what I did in builderCI ... then I agree wholeheartedly that a failover of some sort is called for when trying to bootstrap the latam mirror support ... squeaksource was dead at the time and I was in a hurry ... (haven't we heard that before) ... I'd welcome improvements there....
I'm trying a hack there now: basically, revert to using SS for finding ObjectsAsMethodWrappers and MontiRedirect, and selectively add the LatAm redirect. Not great, because we're _still_ using a single point of failure.
A fail-over scheme for FFI or any arbitrary projects (is that what you're getting at?) is a bit more difficult, but I'd definitely be interested in seeing what you're thinking ...
This is what I'm getting at. I'll see what I can think up. frank
Dale
On 22 August 2012 21:59, Frank Shearar <frank.shearar@gmail.com> wrote:
On 22 August 2012 21:08, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, August 22, 2012 11:56:12 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 19:33, Dale Henrichs <dhenrich@vmware.com> wrote: | > 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,
If you're talking about what I did in builderCI ... then I agree wholeheartedly that a failover of some sort is called for when trying to bootstrap the latam mirror support ... squeaksource was dead at the time and I was in a hurry ... (haven't we heard that before) ... I'd welcome improvements there....
I'm trying a hack there now: basically, revert to using SS for finding ObjectsAsMethodWrappers and MontiRedirect, and selectively add the LatAm redirect. Not great, because we're _still_ using a single point of failure.
A fail-over scheme for FFI or any arbitrary projects (is that what you're getting at?) is a bit more difficult, but I'd definitely be interested in seeing what you're thinking ...
This is what I'm getting at. I'll see what I can think up.
Well, it does seem to work, even though it's a stinky hack. I wrote a wrapper that inspects the package you're trying to load, and adds a few possible places where you might find it, and installed the wrapper on MetacelloLoaderPolicy >> #overrideRepositories. Hm. "Seems to work" might actually not be meaningful: is it the case that #overrideRepositories always returns the list of repos to search? Or is there a flag that says "use the config's repos, unless there are overrides"? If #overrideRepositories is always used, this _should_ work. Take a look at the wrapper [1] and the builderCI changes [2] and let me know what you think. frank [1] http://ss3.gemstone.com/ss/Scratchpad-fbs/MetacelloBuildOverrides-fbs.2.mcz [2] https://github.com/frankshearar/builderCI/commit/e1aec187d3d4ca5ec919886d88f...
frank
Dale
Frank, overrideRepositories: overrides all of the repositories used during the load ... it was primarily intended to be used by folks wanting to isolate their development environment from the turbulent internets .... it is not quite as useful for trying to switch between multiple mirrors, you have to provide a complete set of repositories that are up and contain the packages ... Each project can specify primary and mirror repositories in their own configuration. Of course the problem comes up when the mirror repository is down, or the project is only hosted on one repository... Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, September 5, 2012 3:42:55 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 21:59, Frank Shearar <frank.shearar@gmail.com> | wrote: | > On 22 August 2012 21:08, Dale Henrichs <dhenrich@vmware.com> wrote: | >> | >> | >> ----- Original Message ----- | >> | From: "Frank Shearar" <frank.shearar@gmail.com> | >> | To: Pharo-project@lists.gforge.inria.fr | >> | Sent: Wednesday, August 22, 2012 11:56:12 AM | >> | Subject: Re: [Pharo-project] latam mirror down? | >> | | >> | On 22 August 2012 19:33, Dale Henrichs <dhenrich@vmware.com> | >> | wrote: | >> | > 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, | >> | >> If you're talking about what I did in builderCI ... then I agree | >> wholeheartedly that a failover of some sort is called for when | >> trying to bootstrap the latam mirror support ... squeaksource was | >> dead at the time and I was in a hurry ... (haven't we heard that | >> before) ... I'd welcome improvements there.... | > | > I'm trying a hack there now: basically, revert to using SS for | > finding | > ObjectsAsMethodWrappers and MontiRedirect, and selectively add the | > LatAm redirect. Not great, because we're _still_ using a single | > point | > of failure. | > | >> A fail-over scheme for FFI or any arbitrary projects (is that what | >> you're getting at?) is a bit more difficult, but I'd definitely | >> be interested in seeing what you're thinking ... | > | > This is what I'm getting at. I'll see what I can think up. | | Well, it does seem to work, even though it's a stinky hack. I wrote a | wrapper that inspects the package you're trying to load, and adds a | few possible places where you might find it, and installed the | wrapper | on MetacelloLoaderPolicy >> #overrideRepositories. | | Hm. "Seems to work" might actually not be meaningful: is it the case | that #overrideRepositories always returns the list of repos to | search? | Or is there a flag that says "use the config's repos, unless there | are | overrides"? If #overrideRepositories is always used, this _should_ | work. | | Take a look at the wrapper [1] and the builderCI changes [2] and let | me know what you think. | | frank | | [1] | http://ss3.gemstone.com/ss/Scratchpad-fbs/MetacelloBuildOverrides-fbs.2.mcz | [2] | https://github.com/frankshearar/builderCI/commit/e1aec187d3d4ca5ec919886d88f... | | > frank | > | >> Dale | >> | |
On 5 September 2012 19:18, Dale Henrichs <dhenrich@vmware.com> wrote:
Frank,
overrideRepositories: overrides all of the repositories used during the load ... it was primarily intended to be used by folks wanting to isolate their development environment from the turbulent internets .... it is not quite as useful for trying to switch between multiple mirrors, you have to provide a complete set of repositories that are up and contain the packages ...
Do you mean that Metacello will choose, for an entire load, a repository? I'd imagined that it would, for each load of each package, try the repositories in order. But if it's per entire load, then you'd need each repo-containing server to have the full set of packages. That would be more awkward.
Each project can specify primary and mirror repositories in their own configuration.
Yes, which is the problem: how many ConfigurationOfs out there say "SS, but fall back to LatAM", or "use the canonical, but fall back to SS"? I know _yours_ do, but I suspect most won't.
Of course the problem comes up when the mirror repository is down, or the project is only hosted on one repository...
If a package is hosted on SS, it will be on LatAm too, so all SS-hosted packages can now come from either. frank
Dale
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, September 5, 2012 3:42:55 AM | Subject: Re: [Pharo-project] latam mirror down? | | On 22 August 2012 21:59, Frank Shearar <frank.shearar@gmail.com> | wrote: | > On 22 August 2012 21:08, Dale Henrichs <dhenrich@vmware.com> wrote: | >> | >> | >> ----- Original Message ----- | >> | From: "Frank Shearar" <frank.shearar@gmail.com> | >> | To: Pharo-project@lists.gforge.inria.fr | >> | Sent: Wednesday, August 22, 2012 11:56:12 AM | >> | Subject: Re: [Pharo-project] latam mirror down? | >> | | >> | On 22 August 2012 19:33, Dale Henrichs <dhenrich@vmware.com> | >> | wrote: | >> | > 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, | >> | >> If you're talking about what I did in builderCI ... then I agree | >> wholeheartedly that a failover of some sort is called for when | >> trying to bootstrap the latam mirror support ... squeaksource was | >> dead at the time and I was in a hurry ... (haven't we heard that | >> before) ... I'd welcome improvements there.... | > | > I'm trying a hack there now: basically, revert to using SS for | > finding | > ObjectsAsMethodWrappers and MontiRedirect, and selectively add the | > LatAm redirect. Not great, because we're _still_ using a single | > point | > of failure. | > | >> A fail-over scheme for FFI or any arbitrary projects (is that what | >> you're getting at?) is a bit more difficult, but I'd definitely | >> be interested in seeing what you're thinking ... | > | > This is what I'm getting at. I'll see what I can think up. | | Well, it does seem to work, even though it's a stinky hack. I wrote a | wrapper that inspects the package you're trying to load, and adds a | few possible places where you might find it, and installed the | wrapper | on MetacelloLoaderPolicy >> #overrideRepositories. | | Hm. "Seems to work" might actually not be meaningful: is it the case | that #overrideRepositories always returns the list of repos to | search? | Or is there a flag that says "use the config's repos, unless there | are | overrides"? If #overrideRepositories is always used, this _should_ | work. | | Take a look at the wrapper [1] and the builderCI changes [2] and let | me know what you think. | | frank | | [1] | http://ss3.gemstone.com/ss/Scratchpad-fbs/MetacelloBuildOverrides-fbs.2.mcz | [2] | https://github.com/frankshearar/builderCI/commit/e1aec187d3d4ca5ec919886d88f... | | > frank | > | >> Dale | >> | |
----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, September 5, 2012 1:41:00 PM | Subject: Re: [Pharo-project] latam mirror down? | | On 5 September 2012 19:18, Dale Henrichs <dhenrich@vmware.com> wrote: | > Frank, | > | > overrideRepositories: overrides all of the repositories used during | > the load ... it was primarily intended to be used by folks wanting | > to isolate their development environment from the turbulent | > internets .... it is not quite as useful for trying to switch | > between multiple mirrors, you have to provide a complete set of | > repositories that are up and contain the packages ... | | Do you mean that Metacello will choose, for an entire load, a | repository? I'd imagined that it would, for each load of each | package, | try the repositories in order. But if it's per entire load, then | you'd | need each repo-containing server to have the full set of packages. | That would be more awkward. Metacello will choose from the entire list of repositories ... Metacello uses Gofer and Gofer does not scan in order... Supplying multiple repositories will kinda work, but as I said, the overrideRepositories feature was not intended as a solution for repositories going off-line. | | > Each project can specify primary and mirror repositories in their | > own configuration. | | Yes, which is the problem: how many ConfigurationOfs out there say | "SS, but fall back to LatAM", or "use the canonical, but fall back to | SS"? I know _yours_ do, but I suspect most won't. | | > Of course the problem comes up when the mirror repository is down, | > or the project is only hosted on one repository... | | If a package is hosted on SS, it will be on LatAm too, so all | SS-hosted packages can now come from either. This is the desired effect, methinks. | | frank Dale
participants (2)
-
Dale Henrichs -
Frank Shearar