Disabling package cache
Locked
 
Administrator
|
When publishing configs, I've been surprised a few times because a config worked on my machine, but when others tried to load, the packages could not be found. The problem was that the packages were in my package cache. How do I get around this? I searched the list(s) for "metacello disable cache", but didn't see anything promising.
Thanks!
Cheers,
Sean |
|
|
Sean, I'm not sure that this is a Metacello issue ... The package-cache is a feature of Monticello ... I suppose the "poor man's" disable package-cache would be something like the following:
| originalCacheDirectory newCacheDirectory | originalCacheDirectory := MCCacheRepository cacheDirectory. [ MCCacheRepository cacheDirectory: (...empty directory stuff...).
.... test log....] ensure: [MCCacheRepository cacheDirectory: originalCacheDirectory]. Not sure if this kind thing would belong in Metacello proper or not... On second thought, a disablePackageCache option for Metacello just might make sense: Metacello new configuration: 'blah' ; .... disablePackageCache;
load. Dale Dale On Mon, Apr 21, 2014 at 6:07 PM, Sean P. DeNigris <[hidden email]> wrote: When publishing configs, I've been surprised a few times because a config You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
You can use the disable cache mechanism from Gofer: Gofer new disablePackageCache; ... Doru On Tue, Apr 22, 2014 at 5:48 AM, Dale Henrichs <[hidden email]> wrote:
"Every thing has its own flow"
You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
Thanks Doru, but that seems to only disable for one Gofer operation. I want to load a config from my package cache, and then "config project stableVersion load" with the cache disabled. Dale's snippet looks like what I need...
Cheers,
Sean |
|
Administrator
|
I later found "MCCacheRepository disableCacheDuring: aBlock", which I haven't tested but looks just right!
Cheers,
Sean |
|
|
Sean, Well, I happen to be poised to finish several weeks worth of intensive work on Metacello (mainly aimed at new features) and once I finish it will probably be a while before I revisit Metacello for anything but critical bugfixes ... Before I pull the trigger I would like to consider adding `disablePackageCache` to the Metacello scripting API. Internally, I have had the ability to disable the package cache for quite a long time ... Mainly I've used it for tests where random packages from other tests could produce random tests results ... the use case for tests, involved setting a loader property in the project method: project loader: (project loaderClass new shouldDisablePackageCache: true; yourself). but I am concerned that if I naively provide an api to this property, it may not quite work as expected (and if I change the semantics of shouldDisablePackageCache I may break a slew of tests:). Soooo, I would like to understand how disabling the package cache makes it possible for you to discover bugs in your configuration? Have you tried validating the configuration? If your configuration is sensitive to the contents of the package-cache then your configuration may not work correctly for other folks either, so it seems to be a pretty precarious situation to be in ... so I want to understand this a bit more. Dale On Sat, Oct 18, 2014 at 11:15 AM, Sean P. DeNigris <[hidden email]> wrote: Sean P. DeNigris wrote You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
Exactly! This is precisely why I want to disable the cache for testing. I've had situations where my configuration specified packages which I had committed locally, but had forgotten to copy the mczs to their proper repository. So my configuration worked perfectly on my machine by pulling the required versions from my package cache, but then users said (correctly) that the config was broken. As a pre-release step, I want to load via the config with the cache disabled to simulate a user's context. Does that make sense? I haven't run into this problem in a while so the details may be a bit off... Thanks!
Cheers,
Sean |
|
|
Sean, I'm inclined to say "Yeah but...".... the only way to know whether your configuration loads correctly is to test in a clean environment and in a clean image ... I rely on travis tests passing before trusting that my configuration is good despite local testing:) In the last week I've stopped depending upon disablePackageCache and taken to nuking the package-cache during test setup ... so in my testing environment I have not found disablePackageCache to be sufficient (and before you ask, I have not spent any time attempting to figure out why, I just know that nuking the package-cache leaves nothing to chance:) ... but this is still in the testing environment... Each api feature contains a cost for testing and maintenance and I'm afraid that if I include a feature related to the package-cache (which is starting to have widely varying behaviors) I will be faced with trying to track down subtle bugs in this feature and even worse yet devise test cases that reproduce these subtle problems:) Soooo, on further review I'm inclined to fall back to my initial response which is to rely on platform level support for disabling the package-cache ... BTW, I looked at the disableCacheDuring: in the last week, but since it was not available on all platforms and as I said the implementation is diverging, I didn't think it was worth devoting time to disabling and settled for nuking:) Dale On Sat, Oct 18, 2014 at 12:04 PM, Sean P. DeNigris <[hidden email]> wrote: Dale Henrichs-3 wrote You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |