[Glass] loading glass questions

[Otto Behrens]

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.