As this is a real nuisance, I might have a partial solution — remove the
repos :)
Apart from contributing to pharo (which is done in clean images) I never
needed reference to those repositories, so I don't see why I would need
them there.
So a startup script to the rescue
StartupPreferencesLoader default executeAtomicItems: {
StartupAction
name: 'remove references to Pharo50 and Pharo50Inbox'
code: [
|rx group|
rx := '([0-9]{5})' asRegex.
(rx matchesPrefix: Smalltalk image shortImageName) ifFalse: [
group := MCRepositoryGroup default.
group repositories detect: [ :each |
each location includesSubstring: 'Pharo/Pharo50Inbox/main'
] ifFound: [ :repo |
group removeRepository: repo
].
"This repo is added twice for whatever reason (once main and once main/ or
whatever."
group repositories detect: [ :each |
each location includesSubstring: 'Pharo/Pharo50/main'
] ifFound: [ :repo |
group removeRepository: repo
].
group repositories detect: [ :each |
each location includesSubstring: 'Pharo/Pharo50/main'
] ifFound: [ :repo |
group removeRepository: repo
]
]
]
runOnce: true.
}
Peter
On Fri, Jun 3, 2016 at 8:49 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:
>
>
> On 6/3/16 2:43 AM, Otto Behrens wrote:
>
> For FileTree repos it is even better to just load the package (Monticello
> does a good job of only loading the changed packages and we're looking at
> packages already on disk) ... ... I have an extension to Metacello for
> Filetree repos (it's only been around for about 3 years) that ignores
> version numbers and "loads" all of the packages from the the repo (I
> mentioned _this_ to Thierry:) ... which for FileTree repos is actually the
> proper behavior ... I happen to be very busy at the moment so I don't have
> time to blow the dust off of that extension ... the big gotcha is everyone
> has to have the extension present in their image for this kind of thing to
> work and AFAIK pharo is not kept up-to-date with the latest versions that I
> publish on github, so I'm afraid that much breakage would ensure if only a
> few individuals started using this extension ... Seems to be that we're
> stuck between a rock and a had place... I wish there was a better way to
> keep the Metacello distribution up-to-date in images that I have no control
> over ...
>
> FWIW, I've found that if I manually flush the cache for each package before
> I save it, I don't have to wait the minute or so for all of the repos to be
> refreshed ...
>
> Dale, will you please publish this stuff somewhere, with dust on, as
> is? (Or tell us where we can find it).
>
> Well let's see there's the Metacello-Cypress package is in the Metacello
> repo[1] and the following should load the Cypress support into an image
> with Metacello already loaded:
>
> Metacello image
> baseline: 'Metacello';
> load: ' Cypress'
>
> To use the Cypress support, implement a #projectClass method in your
> BaselineOf that returns MetacelloCypressBaselineProject:
>
> projectClass
> ^MetacelloCypressBaselineProject
>
> and you should be in business ...
>
> IIRC the MetacelloCypressBaselineProject should be usable with any
> BaselineOf. The only difference for Cypress is that Monticello versions are
> ignored when making loading decisions --- at least that's the intent.
>
> Before going full scale, we'd need to add some tests for the Cypress
> project and of course make sure that the Cypress support gets loaded by
> default ...
>
> [1]
> https://github.com/dalehenrich/metacello-work/tree/master/repository/Metacello-Cypress.package
>
> We've just battled sooo much in this area. I wonder if it is worth it
> to think again about this whole git / monticello / metacello thing.
> For me, it's just too much to comprehend. As soon as I dig into
> something here, I get lost within minutes.
>
> I believe the complexity has to do with trying to maintain too many
> different ways of solving the problem. We are trying to keep things
> (Monticello / Metacello) working with or without git or filetree or
> whatever else people are using.
>
> I would really like to do merging in git and just have a fast and
> simple way of loading / compiling into an image (and GemStone). I do
> not want a package cache, 3 way merging and all the other things,
> because it makes what I end up with unpredictable. But you see, other
> people want to work in other ways, which I understand. My perception
> is that the result is messy.
>
> We should try to strive more towards *fewer* ways of doing things,
> without killing innovation to try different ways. It feels as if there
> are enormous, yet very incomplete silos of efforts to solve problems.
>
>
> I basically agree with everything you say here.
>
> I added the Cypress package support several years ago when Richard Sargent
> wrote a Cypress implementation for the base GemStone[2], so we've had the
> bits a pieces necessary for a cleaner simpler mechanism for a while at
> least for GemStone ...
>
> I would like to distinguish between Cypress and FileTree.
>
> FileTree was created (by you:) to support disk-based repos while
> maintaining full Monticello compatibility. Over the years I've (stubbornly)
> maintained that the Monticello meta data be preserved in FileTree
> repositories. By preserving Monticello meta data, the packages can be
> easily moved between FileTree and SmalltalkHub, etc. while faithfully
> preserving the Monticello ancestry. Maintaining Monticello meta data is
> critical for folks to be able to "dip their toe into the git pool" while
> preserving Monticello ancestry.
>
> When I say "Cypress" (as opposed to FileTree), I think of a stripped down
> implementation of FileTree where Monticello meta data is not stored on disk
> and, perhaps more importantly the package loading code, in-image package
> management and tool support is also stripped down to support a simple model
> where package history and version numbers are non-existent. This particular
> model is aimed at projects that spend their entire lives in "git" repos and
> there is no desire, nor need to keep a parallel ancestry in the Monticello
> meta data and I think that what you are asking for ... in fact with Cypress
> package names do not need any package meta data ... the SHA of the commit
> is all that is needed to uniquely identify packages [in tODE the
> development environment is focused on the Metacello project and the package
> is not really the focus, so right now the Metacello registry is capable of
> tracking the SHA of the commit used to load a _project_, so I don't think
> that a package needs to have any additional meta data like UUID or version
> number or and the SHA of the commit at _project_ load time is all that is
> needed]
>
> For Pharo, I think that GitFileTree provides you with support for a
> metadata-less disk footprint, but the in-image support is still based on
> Monticello --- at least that's what I understand about GitFileTree, since
> up to now I haven't spent any time working with it ... that will change
> this summer as I am working on a project in Pharo5. GitFileTree is an
> extension of the "FileTree model" in that it is compatible with the current
> in-image tools that all pretty much expect Monticello packages --- this
> approach is needed because it is a big job to incorporate an alternate
> source code management scheme in the in-image tools across the board ... If
> one were to switch the pharo tool focus from the _package_ (Monticello
> Browser) to the the _project_ (Project Browser) there would be additional
> work to be done: 'save' of project means save all dirty packages in project
> as well as a `git commit`, 'diff' of project means show changes for all
> dirty packages in project, and there would be analogs for 'load', 'revert',
> 'history' etc.
>
> For GemStone, I have written tODE to be git-aware from the beginning and I
> have built tools to support Cypress package management as well[3] although
> they _are_ 3 years old and would deserve additional work ... Internally we
> are seriously considering adding Cypress support to the base image for the
> GemStone 3.4 release and of course in the process of doing that work, I
> assume that we'd make the code available for use in 3.2 and 3.3 as well.
>
> In the short term I think that a combination of Cypress package support
> from Metacello, GitFileTree in Pharo and the updating of the Cypress tools
> for tODE will allow you to share packages between Pharo and GemStone
> without needing to create and maintain Monticello meta data ... in the
> midterm Cypress support is slated for this year and if necessary I can make
> changes to the current tODE FileTree implementation to allow the writing of
> metadata-less packages -- I think GitFileTree records whether or not a
> repository is metadata-less in a repository property file that I can use if
> necessary ...
>
> Does this make sense?
>
> Dale
>
> [2] https://github.com/rjsargent/CypressReferenceImplementation
> [3]
> https://github.com/dalehenrich/tode/tree/master/repository/Topez-Server-CypressTools.package
>
>
