Ben,
Hmmm, I could make the use of #stable a Critical Warning:
"MetacelloValidationCriticalWarning indicates that there is a logical
inconsistency that may not be intentional and that could cause incorrect
loads". I've submitted a Metacello issue #350[1] for this.
If I thought that folks regularly used configuration validation, I
wouldn't have to do much else:)
Of course there are ancient configurations where #stable still must be
used. There are validation pragmas that allow one to filter out "know
exceptions" for the validator so that only new configs would generate
the "critical warning" ...
I'm reluctant to go much further than this ... of course tools could be
more aggressive in stamping out the use of #stable...
Dale
[1] https://github.com/dalehenrich/metacello-work/issues/350
On 5/28/15 4:57 PM, Ben Coman wrote:
On Fri, May 29, 2015 at 6:14 AM, Dale Henrichs
<[email protected]> wrote:
Andrei,
1) The old configuration load api is non-deterministic, especially when used
with large configurations, Metacello will not downgrade a package, so if
(using the old api) Metacello decides that a newer version of a
configuration is present, then it will use the newer (and possibly incorrect
version). Keep in mind that pre-loaded packages in Pharo can influence this
non-deterministic calculation.
I don't know for certain that using the old API is the culprit. The only way
for me to understand where the issue might lie is for me to look at the
Transcript output of a load.
2) I'm not sure that Moose is loadable in Pharo3.0 ... If things are not
actively tested then they are likely to quit working over time and I'd guess
this is the case for Pharo3.0 and Moose.
3) using #stable is a very inaccurate way of specifying a symbolic version.
The Seaside folks have started using version-based symbolic versions like:
#'release3', #'release3.1', #'release3.2' a while ago and I think this is a
very good way to leverage symbolic versions ... #stable can be changed and
in the mind of the developer #stable is now version 4.0.0, while a number of
older configurations will consider #stable to be version 3.0.0 ... it
doesn't take long the #stable version universe to be completely confused ...
For a Configuration newbie it may seem intuitive for a Configuration
to dependend on other Configuration's #stable without realising the
hole they are digging. You could say its easy to shoot yourself in
the foot with #stable? So maybe #stable only makes sense as a
*convenience* for interactive users at the "command line." It might
be reasonable for the system to block use of #stable within a
Configuration (with a deprecation warning and bypass method like
#allowNestedStable)
cheers -ben
While I suspect that the current #stable version of Moose does not run on
Pharo3.0, if version-based symbolic versions had been used back then the
configurations would likely still be usable ...
Again, I am just guessing ... analysis of the Transcript output would give
me better clues ...
Using the new Metacello scripting API:
Metacello new
configuration: 'Moose';
version: #stable;
repository: '???';
load
does a load without without calculating the #currentVersion and should be
deterministic with respect to loaded versions ... this only addresses the
first point above. If points 2 or 3 are involved, then it may be more
difficult to solve the problem ...
BTW, sorry for taking so long to get back to you ... in the last month I've
taken a long overdue vacation (and did not even open my laptop:) and have
been working exclusively on GemStone 3.3 ... I'm nearly finished with my
main commitments for GemStone 3.3 and as I come up for air, I'm working off
my email backlog:)
Dale
On 5/18/15 5:56 AM, Andrei Chis wrote:
Hi,
If I specify a stable version for a platform (spec for: #'pharo3.x'
version: '3.0.6'.), shouldn't Metacello load that version?
Concrete use-case: loading ConfigurationOfMoose in Pharo 3
- ConfigurationOfMoose specifies version 5.0 as stable for Pharo 3
- ConfigurationOfMoose version 5.0 loads ConfigurationOfGlamour #stable
- ConfigurationOfGlamour specifies version 3.0.6 as stable for Pharo 3
(spec for: #'pharo3.x' version: '3.0.6')
Loading ConfigurationOfMoose [1] in Pharo 3 loads version 3.0.9 for
ConfigurationOfGlamour.
Updating Monticello leads to the same result.
Did I misunderstood something about how monticello works?
Any idea how to debug this?
Cheers,
Andrei
[1] (ConfigurationOfMoose project version: #'stable') record loadDirective
