Hi Tobias!
For one reason or another, I happen to have the Class `GRPlaform` in my image but not actually Grease installed. Now suppose I use the SqueakMap entry for Seaside. It installs but fails with —seemingly random—errors. What happens here? The install _script_ for Seaside tries to determine whether Grease is installed by checking whether the class `GRPlatform` is in the System. Yes, this is a pathological case but I chose it to illustrate the underlying problem:
The SqueakMap install scripts are _imperative_ load scripts. That is one of the key points of Metacello. To quote the web site: Declarative modeling. A Metacello project has named versions consisting of lists of explicit Monticello package versions. Dependencies are explicitly expressed in terms of named versions of required projects. A required project is a reference to another Metacello project.
"Declarative" is not a requirement. The requirement is simply for fixed-configurations to _work_ in legacy releases of Squeak (and for head-configurations to support collaboration). The SM entry does load explicit versions of required packages and projects, so I see no difference here in terms of a fixed-config consumption.
Right. I am afraid I have to agree with this point. I, however, think in terms of maintainability, a declarative way of specifying Software Configurations (what we are essentially talking about, no?) clearly wins.
By declarative, I assume you mean a list of specific versions of specific packages to run in a specific release of Squeak (a.k.a., a "fixed-configuration"). I don't know how to be anymore declarative than that.
My main requirement is for any newbie, or an archaeologist from the future, to be able to figure out how to install a working piece of software without having to ask questions on the mailing list.
Do Metacello configurations declare which specific release of Squeak that configuration is for? If so, then I think it is nearly equivalent to what SqueakMap offers in terms of the promise of a stable configuration that will work for years to come. If not, then I think that is a significant shortcoming to using Metacello to meet my requirement. One could make a fixed-configuration that works for Squeak 4.4 today, but will someone remember that fixed-config is for Squeak 4.4, 5 years from now when Squeak 5.5 is the current? Or is it back to trolling through the mailing lists to figure it out?
In the given case, when I install Seaside via the Metacello configuration, the Seaside config specifies a dependency on Grease declaratively and Metacello resolves this. In turn, Grease comes with a Metacello config and Metacello then can determine whether Grease is already installed via Metacello. In our case, it would determine that Grease is not installed and would try to install it. _This_ certainly would fail, as our `GRPlatform` class would conflict the one of Grease, but at least we would _know_ that this is the problem: Monticello would notify us that we are trying to overwrite an existing class.
Sure, the SM script could easily be changed to also fail, but that does not allow two independent projects that both require Grease to be easily consumed.
What do you mean by Consumed?
Installing and using a piece of software.
Incidentally, one problem I have with Metacello is its opaqueness -- I can't easily look at a config and know what I'm going to get -- the word "Development" is not meaningful to me, I want to know what packages will be loaded.
It depends on perspective. I find a "description" of what will be loaded more transparent than a code snippet that can do about just anything.
So, requirement #13 at:
http://wiki.squeak.org/squeak/6183
is:
"13. Must be able to browse code before installing it, as a security measure."
So it is not just about "knowing what I'm going to get" but also being able to *easily* review and even debug the installation process. I suppose this would be possible with Metacello configs too, just not as easy as a straight script which spells out the exact versions of every package you'll get.
Right. Dale intended the development model for Metacello Versions quite open. The MetacelloRepository's out there (I think there are 3–4) are all world-writable. Not every developer is paying attention to the quasi-rule that a released version of a Configuration should not be touched. This had me bothering quite a few times, and this is also the case why Seaside 3.0.7 isn't currently installing in Squeak 4.4 via the Configuration.
Ok, Seaside is classic, signature Squeak software so I hope we'll have 3.0.7 working again.
This is unacceptable because it is too high a barrier for newbies. The "Consume" requirement demands it should just-work(tm) with one-click.
Sorry, I cannot follow. What is unacceptable to you here?
That requirement 3 is not met.
"3. Installation must occur with one-click, including all prerequisite packages."
Because there were two pre-req packages that needed to be manually downloaded first. As you said here:
http://forum.world.st/Making-seaside-load-in-Squeak-again-td4672155.html#a46...
No newbie coming into the community to check out Seaside is going to know this, it'll just be "broken" for him.
Since the last Squeak/Seaside one-click (that I built in frustration, and wasn't fully functional, either, due to a buggy OmniBrowser) both Seaside and Squeak evolved. How can we expect it to just work if nobody has a look at it? Am I missing something fundamental here?
Nope. The only things we can expect to work are fixed-configurations that someone had put attention to in the past. Whenever new version of Seaside or Squeak comes out, same attention must be paid to create another fixed-config for that version that will have longevity.
(I wrote:)
Otherwise, it's worth asking, what is the best way for us as a community to keep up a dependably working version of Seaside for Squeak?
We need a person that constantly monitors the development of both?
If there is sufficient interest in Seaside going forward, someone will do it. If not, they won't, but at least we will still always have fixed-configurations working in older Squeak's. If sufficient interest materializes in teh future, those fixed-configs are a good place to start to make a newer working version.
Best, Chris