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
