[Glass] loading glass questions

Sun Nov 17 22:51:23 PST 2013

I'll do what I can, but I really have targetted the Metacello Preview to address exactly the problems you are experiencing and I believe in striking while the iron is hot ... so I'm part way to building an example and will need to do some gemstone product work tomorrow:)

Dale

----- Original Message -----
| 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 6:45:08 PM
| Subject: Re: [Glass] loading glass questions
| 
| Thanks Dale, such an example will be helpful. I did not expect of you
| to jump in right now and do this, thanks.
| 
| > 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.
| > |
| 