[Glass] loading glass questions

Sun Nov 17 14:35:51 PST 2013

Otto,

My short answer is that your rant is absolutely valid. With the Metacello Preview I am actually attempting to achieve exactly what you are asking for ... From my perspective it should be possible for a team to fork the git repos for all of the external projects that they depend upon then do project loads without having to edit every single configuration or baseline that references the project ... If I'm not mistaken this is exactly what you are looking for...

The long answer is that we have to address a couple of fundamental questions:

 1. does the Metacello Preview actually meet your needs, or am I on crack?
 2. how do you get FileTree and Metacello Preview loaded?
 3. what will you need to change in your current environment to take 
    advantage of the Metacello Preview?

I think we need to take these questions one at a time ... 

I can put together an example of how you can leverage the Metacello Preview. In the example, I will set up a sample local project that references one project on github and another project on ss3. Then show the steps where you can:

  a) fork the github-based repo to your local disk; 
  b) copy the ss3 project to a disk based repository; and 
  c) arrange to do a load without having to edit any of the configurations ...

If I'm not mistaken, this is the kind of thing you want to do ... if I am mistaken, we can tweak the example so that it matches your needs and then make sure that the Metacello Preview operates to your satisfaction ...

Once you've seen and played with a working example, we can start tackling the other questions ... 

So what do you think?

I'm going to start working on the examples right now...

Dale

| From: "Otto Behrens" <otto at finworks.biz>
| To: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| Cc: glass at lists.gemtalksystems.com
| Sent: Sunday, November 17, 2013 11:52:50 AM
| Subject: Re: [Glass] loading glass questions
| 
| Thanks for the help
| 
| > I can imagine that you will be getting mixed results when trying to
| > use GLASS1 with other packages ... You do an explicit load of
| > ConfigurationOfGsMisc which is also covered by packages in GLASS1
| > and that may be confusing things
| 
| I start off with a seaside database (or should I do the whole
| bootstrapping thing myself?) or with a production database, which
| will
| always have other MC & glass packages in there.
| 
| Well, if I don't load ConfigurationOfGsMisc, things break. I get a
| MetacelloVersionDoesNotExistError, versionString = 0.241.1, seemingly
| on ConfigurationOfGsMisc, something to do with
| System-Digital-Signatures. And this is probably because there is an
| old ConfigurationOfGsMisc loaded already.
| 
| I've encountered this a few times. ConfigurationOf classes are not
| updated as they are encountered. I have to load them beforehand.
| 
| >  Metacello new
| >   baseline: 'Metacello';
| >   repository:
| >   'github://dalehenrich/metacello-work:master/repository';
| >   load: 'ALL'.
| >   ] on: Warning
| >     do: [:ex |
| >       Transcript cr; show: ex description.
| >       ex resume].
| >
| > Instead of loading 1.0-beta.32 of Metacello ... Of course, you
| > should make a local clone of Metacello and reference it as well
| > ...
| 
| At this point in time, Metacello does not exist in my DB, but
| monticello does. So I'm trying to get it in. Filetree is not
| bootstrapped either. How do I get it in then? Issue is bootstrapping
| of filetree + metacello. Currently use seaside image, with Monticello
| and load from package files stored in a git repo.
| 
| > Instead of using repository overrides, I think that you should use
| > `project locks`[1]. By using `locks` you will be able to point
| > directly at your cloned repositories instead of having to maintain
| > a monster thirdparty mcz repo...which is more important for the
| > git-based repos ...
| 
| I don't know where to do this. I've got 1 class called
| ConfigurationOfWonkaRuntime. (Yes, don't laugh, the project name is
| Wonka). Runtime is all the base stuff we use like seaside & magritte.
| So in there, I've got:
| 
|                         baseline: 'Seaside'
|                             with: [
|                                     spec
|                                         className:
|                                         'BaselineOfSeaside30';
|                                         repository: self class
| localThirdPartySeasideRepository;
|                                         loads: #('Base'
| 'Scriptaculous-Components' 'JQuery-UI') ];
| 
| and later on
| 
|                         project: 'Magritte3 Base'
|                             with: [
|                                     spec
|                                         className:
|                                         'ConfigurationOfMagritte3';
|                                         loads: #('Magritte-Seaside'
| 'Deprecated');
|                                         repository:
| 'http://www.squeaksource.com/MetacelloRepository' ];
| 
| which defines a dependency on seaside 30.
| 
| This is really confusing. I wish I could just switch all this off. I
| don't want Metacello to remember any repository, or where a package
| came from. I want to just tell it where the packages are and it must
| just use that. I *never* want it to fetch *any* package from a remote
| repo. This is pain. I don't understand.
| 
| To me, it is quite simple.
| - We use git.
| - Or for that matter, any old version control system.
| - We take a snapshot (read git commit) of all the software, image
| files, scripts and configs that work together.
| - That's a version.
| - We want to deploy *that* version. (deploy = upgrade existing /
| build
| new db on a bootstrapped one)
| - Reliably.
| - We can't depend on github or n external repositories. We want to
| know that once a particular version is checked out, it will deploy.
| - We have all the packages we've tested manually and have run through
| our tests together in a version
| - We don't want any package caching. Just get it from disk.
| - We don't want fancy upgrading of packages, just delete all the code
| and load from scratch (Upgrading of packages almost never work as
| overridden methods are removed.)
| - We don't want to specify a version of any package anywhere because
| we've got the version we want in the repo
| 
| Pardon the dump. We seem to have conflicting approaches. I don't
| understand how people can get a reliably working system in any other
| way. Please enlighten me (no sarcasm intended). We've been trying to
| upgrade this stuff for 1 year now. This is way too costly, and
| frustrating.
| 
| > I think that the best answer will be that we'll actually need to
| > change how the GLASS dependencies are referenced from the various
| > projects when using GLASS1 because we want to reference the
| > version of GLASS1 instead of the versions of the various sub
| > projects ...
| >
| > I also don't like the name GLASS1 and have been considering a
| > rename to something more descriptive like
| > GsWebEdition(?)...Seaside hasn't been included in the GLASS
| > project for quite some time, so the GLASS acronym is a bit
| > confusing for folks ...
| >
| > To do this correctly, we'd need to invent new platform attributes
| > when using GsWebEdition (I'll use this name for now) so that the
| > metacello configs can be correctly editted, Instead of:
| >
| >    gemstone, gemstone2.4.x, gemstone3.x, etc.
| >
| > we'd use
| >
| >   gswebedition, gswebedition2.4.x, gswebedition3.x, etc.
| >
| > I think this would give us the cleanest break ... It entails
| > editting a bunch of configurations, but I the move to GsWebEdition
| > is a pretty significant move and I think warrants this kind of
| > treatment ...
| 
| Yes, agree with all of the above.
| 
| > Fortunately, I'm getting close to finished with the internal
| > GemStone work I've been spending most of my time on so I should
| > have more time to devote to working on this transition...
| 
| Thanks for all your effort.
| 