What sets the Monticello Local Cache Directory default in a new image?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

What sets the Monticello Local Cache Directory default in a new image?

Tim Mackinnon
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?

Tim
Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Mariano Martinez Peck


On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--
Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Tim Mackinnon
Hey thanks - that seems like a good strategy (I hadn’t though of sharing the GT ones as well).

However, I’m still curious how/why a new image would pick up settings from what I did in another image (at least I think thats what its done - certainly the directory it shows in my fresh image is not File @pharo-local/package-cache like I would expect it to be?

With regards to the GT settings - how does it work if you share them - do they happily co-exist? The stash one is also quite new to me - Sven mentioned it a few weeks ago as I was confused how the playground got saved (I’m still not clear) - but he suggested double-clicking the title and giving the tab a name. Are these named ones the stashed ones (it looks like it). And do stashed ones honour cmd-s to save them? Which then leads to the question, that in different images - if you share the stash then I guess if you want to reload a file, you close that playground and then pick it again from the list?

Its quite a cool way of working (not perfect) but a real time saver. Thanks for sharing.

Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--

Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Pavel Krivanek-3
Try to run the image with --no-default-preferences.

-- Pavel

2017-08-02 14:37 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hey thanks - that seems like a good strategy (I hadn’t though of sharing the GT ones as well).

However, I’m still curious how/why a new image would pick up settings from what I did in another image (at least I think thats what its done - certainly the directory it shows in my fresh image is not File @pharo-local/package-cache like I would expect it to be?

With regards to the GT settings - how does it work if you share them - do they happily co-exist? The stash one is also quite new to me - Sven mentioned it a few weeks ago as I was confused how the playground got saved (I’m still not clear) - but he suggested double-clicking the title and giving the tab a name. Are these named ones the stashed ones (it looks like it). And do stashed ones honour cmd-s to save them? Which then leads to the question, that in different images - if you share the stash then I guess if you want to reload a file, you close that playground and then pick it again from the list?

Its quite a cool way of working (not perfect) but a real time saver. Thanks for sharing.

Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--


Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Tim Mackinnon
Ahhhh that’s how it works… StartupPreferencesHandler and its in my user/Library/Preferences/Pharo/6.0 folder…

You learn something new every day (minute it seems lately)

Tim

On 2 Aug 2017, at 14:04, Pavel Krivanek <[hidden email]> wrote:

Try to run the image with --no-default-preferences.

-- Pavel

2017-08-02 14:37 GMT+02:00 Tim Mackinnon <[hidden email]>:
Hey thanks - that seems like a good strategy (I hadn’t though of sharing the GT ones as well).

However, I’m still curious how/why a new image would pick up settings from what I did in another image (at least I think thats what its done - certainly the directory it shows in my fresh image is not File @pharo-local/package-cache like I would expect it to be?

With regards to the GT settings - how does it work if you share them - do they happily co-exist? The stash one is also quite new to me - Sven mentioned it a few weeks ago as I was confused how the playground got saved (I’m still not clear) - but he suggested double-clicking the title and giving the tab a name. Are these named ones the stashed ones (it looks like it). And do stashed ones honour cmd-s to save them? Which then leads to the question, that in different images - if you share the stash then I guess if you want to reload a file, you close that playground and then pick it again from the list?

Its quite a cool way of working (not perfect) but a real time saver. Thanks for sharing.

Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--



Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Tim Mackinnon
In reply to this post by Mariano Martinez Peck
Mariano - out of curiosity, how do you build your image - do you use zero conf and then apply a known .st script? (I used to use pharo launcher back in the day - but now I find that zeroconf is actually handier anyway).

Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--

Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Mariano Martinez Peck


On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <[hidden email]> wrote:
Mariano - out of curiosity, how do you build your image - do you use zero conf and then apply a known .st script? (I used to use pharo launcher back in the day - but now I find that zeroconf is actually handier anyway).


My work flow explained below is only for when I am using stable Pharo for a paid client. In this case, I am not grabbing Pharo latest code all the time. Only every in a while. So, my workflow is as follow:

1) with zero conf I simply grab image and vm (I try to keep my app working with latest stable)
 
2) Apply a known load script that we keep maintained (this is somehwere in a wiki). This script contains:
       2.1) settings of Author, Monticello username and pass etc.
       2.2) Several custom settings/preferences that I like to change to the default image (this could be replaced by startup preferences thingy).
       2.3) Workaround for bugs I hit and that are not backported to stable version.
       2.4) Install 3er party libs I want for my development image (Calypso browser, code critics (now integrated), etc etc).
       2.5) Finally, I load my app code.


3) Once I am done loading all of it, I save that image as "PharoMyAppTemplate.image". And I never do real work with that image. 

4) Each time I need a new image (to make a new feature, a bug fix, whatever) I take "PharoMyAppTemplate.image" and I do a "save as" with either number like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or ""PharoMyAppNewFeature.image" etc. I create these images many times and I don't have a strong policy on when to create new ones. Whenever I create one of these images, I upload my app code to latest code. 

5) Every in a while, I update my template image. Mostly when I change my dependencies. 

I can share the script if you want. 

Cheers,


 
Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--




--
Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Tim Mackinnon
I’d be curious about your script if it is easily handy (I did notice a blog article you wrote on StartupLoader a while back).

By the way - I really appreciated your article "Moving contexts and debuggers between images with Fuel” - it inspired me to figure it out for debugging on AWS lambda (which is very cool BTW - and I’ll write it up soon when I have it bedded in)

Tim

On 2 Aug 2017, at 15:10, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <[hidden email]> wrote:
Mariano - out of curiosity, how do you build your image - do you use zero conf and then apply a known .st script? (I used to use pharo launcher back in the day - but now I find that zeroconf is actually handier anyway).


My work flow explained below is only for when I am using stable Pharo for a paid client. In this case, I am not grabbing Pharo latest code all the time. Only every in a while. So, my workflow is as follow:

1) with zero conf I simply grab image and vm (I try to keep my app working with latest stable)
 
2) Apply a known load script that we keep maintained (this is somehwere in a wiki). This script contains:
       2.1) settings of Author, Monticello username and pass etc.
       2.2) Several custom settings/preferences that I like to change to the default image (this could be replaced by startup preferences thingy).
       2.3) Workaround for bugs I hit and that are not backported to stable version.
       2.4) Install 3er party libs I want for my development image (Calypso browser, code critics (now integrated), etc etc).
       2.5) Finally, I load my app code.


3) Once I am done loading all of it, I save that image as "PharoMyAppTemplate.image". And I never do real work with that image. 

4) Each time I need a new image (to make a new feature, a bug fix, whatever) I take "PharoMyAppTemplate.image" and I do a "save as" with either number like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or ""PharoMyAppNewFeature.image" etc. I create these images many times and I don't have a strong policy on when to create new ones. Whenever I create one of these images, I upload my app code to latest code. 

5) Every in a while, I update my template image. Mostly when I change my dependencies. 

I can share the script if you want. 

Cheers,


 
Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



-- 




-- 

Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Mariano Martinez Peck


On Wed, Aug 2, 2017 at 12:04 PM, Tim Mackinnon <[hidden email]> wrote:
I’d be curious about your script if it is easily handy

As said, nothing fancy at all [1].
And it keeps evolving all the time as Pharo evolves too. 

 
(I did notice a blog article you wrote on StartupLoader a while back).


Yeah, but that post is not a bit outdated as StartupLoader changed quite a bit since I wrote the article.  But the idea is still the same.

 
By the way - I really appreciated your article "Moving contexts and debuggers between images with Fuel” -

Thanks. Yes, that fact made us won the first price [2]. I still remember I was sit on my living room, preparing the demo for ESUG I was thinking how could I show Fuel in a cool manner. I knew at that point we were able to serialize closures, methods, classes, etc... but I just thought "what If I serialize the debugger?". I took me 5 minutes to try it out and realized it worked from the first run hahaa. That was one of my top 5 best programming days of my life hahaha. 

This feature was then used for the "Fuel out stack" and to revive  CI failure tests locally. 

 
it inspired me to figure it out for debugging on AWS lambda (which is very cool BTW - and I’ll write it up soon when I have it bedded in)


Cool. I have been following your emails about having a small image and a small vm and I am very interesting on that. Well, I should be considering which was my PhD [3] hahaha  




Cheers,

 
Tim

On 2 Aug 2017, at 15:10, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <[hidden email]> wrote:
Mariano - out of curiosity, how do you build your image - do you use zero conf and then apply a known .st script? (I used to use pharo launcher back in the day - but now I find that zeroconf is actually handier anyway).


My work flow explained below is only for when I am using stable Pharo for a paid client. In this case, I am not grabbing Pharo latest code all the time. Only every in a while. So, my workflow is as follow:

1) with zero conf I simply grab image and vm (I try to keep my app working with latest stable)
 
2) Apply a known load script that we keep maintained (this is somehwere in a wiki). This script contains:
       2.1) settings of Author, Monticello username and pass etc.
       2.2) Several custom settings/preferences that I like to change to the default image (this could be replaced by startup preferences thingy).
       2.3) Workaround for bugs I hit and that are not backported to stable version.
       2.4) Install 3er party libs I want for my development image (Calypso browser, code critics (now integrated), etc etc).
       2.5) Finally, I load my app code.


3) Once I am done loading all of it, I save that image as "PharoMyAppTemplate.image". And I never do real work with that image. 

4) Each time I need a new image (to make a new feature, a bug fix, whatever) I take "PharoMyAppTemplate.image" and I do a "save as" with either number like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or ""PharoMyAppNewFeature.image" etc. I create these images many times and I don't have a strong policy on when to create new ones. Whenever I create one of these images, I upload my app code to latest code. 

5) Every in a while, I update my template image. Mostly when I change my dependencies. 

I can share the script if you want. 

Cheers,


 
Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



-- 




-- 




--
Reply | Threaded
Open this post in threaded view
|

Re: What sets the Monticello Local Cache Directory default in a new image?

Andrei Chis
In reply to this post by Tim Mackinnon


On Wed, Aug 2, 2017 at 2:37 PM, Tim Mackinnon <[hidden email]> wrote:
Hey thanks - that seems like a good strategy (I hadn’t though of sharing the GT ones as well).

However, I’m still curious how/why a new image would pick up settings from what I did in another image (at least I think thats what its done - certainly the directory it shows in my fresh image is not File @pharo-local/package-cache like I would expect it to be?

With regards to the GT settings - how does it work if you share them - do they happily co-exist?

They should co-exits with no issues if you share the play-cash and play-stash folders between multiple images.
 
The stash one is also quite new to me - Sven mentioned it a few weeks ago as I was confused how the playground got saved (I’m still not clear) - but he suggested double-clicking the title and giving the tab a name. Are these named ones the stashed ones (it looks like it). And do stashed ones honour cmd-s to save them? Which then leads to the question, that in different images - if you share the stash then I guess if you want to reload a file, you close that playground and then pick it again from the list?

The play-stash is for scripts you explicitly give a name. You can double click on the tab and enter a name. Then a file with that name plus a timestamp is created in the play-stash folder. The content gets then saved to that file. Right now you can access the stashed scripts again though spotter by searching for the script name or typing #play to get the cached and stashed pages.

Cheers,
Andrei
 

Its quite a cool way of working (not perfect) but a real time saver. Thanks for sharing.

Tim

On 2 Aug 2017, at 13:24, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images.

Is this normal (does it store this information somewhere on my computer so that different setups can access it)?

At first I thought this was annoying - but I’m now wondering if this is useful as I’m guessing that there isn’t any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory?

What is the recommended strategy?


My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:


" =============== Personal Settings ================ "
MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. 
GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. 


I guess you save stuff:

find /Users/mariano/Pharo/localRepo/ -type f | wc -l                                                                    
   32301

 du -sh /Users/mariano/Pharo/localRepo
6.1G    /Users/mariano/Pharo/localRepo


Not only you save disk space, but also:
1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it).
2) it works as a yet another backup of your code and other packages. 



--