On 4/24/17 9:40 PM, Thierry Goubier wrote:
Hi Dale,
Le 25/04/2017 à 00:02, Dale Henrichs a écrit :
On 04/24/2017 01:49 PM, Thierry Goubier wrote:
Le 17/04/2017 à 22:13, Dale Henrichs a écrit :
On 04/17/2017 12:47 PM, Thierry Goubier wrote:
Hi Dale,
Le 17/04/2017 à 21:05, Dale Henrichs a écrit :
I would think that a `project list` view that made the Metacello
project
registration visible would help developers keep things straight.
It seems that the issue here is that developers can't tell what
projects
are already loaded in the current image and also cannot tell what
version of the project is loaded ... if you are using the `Metacello
new` to load projects, then Metacello knows what projects and what
versions are loaded in the image .... and that informatation really
needs to be exposed to the developers ...
If you have a `project list` then you can do things like
automatically
do a get on a configuration/baseline when a project is loaded via
the
`project list tool` ... there are additional details that need to be
tracked and managed, but without the a basic `project list` the
developer is responsible for "knowing what to do" and the first
step is
to let the developer know exactly which versions of which
projects are
loaded in the base image ...
I wrote some code to that effect in the AltBrowser (gives access to
the project, and all packages loaded via that project, via a
Metacello
registry tag).
It didn't work as well as I expected, in part due to the interaction
between the Metacello registry and package loading into the image.
Nothing undoable, but due to the total lack of Metacello state in the
default Pharo image (nothing is loaded via Metacello in there) and
the
Catalog browser not using Metacello as well, it was a bit too
early to
invest into that.
In short, the Metacello registry provides a nice entry point for a
system browser view of loaded projects and versions, but the Pharo
image building process is not yet there.
If someone is interested, one need to look into the GT extensions for
Metacello objects ... those extensions are a nice source of knowledge
about extracting information from the loaded projects.
This is unfortunate ... I'm willing to help anyone who wants to tackle
this problem as well --- I know a thing or two about Metacello myself
and I've had a working `project list` in tODE for 3-4 years now ... oh
well ...
The code isn't lost anyway. I've reintegrated it as classifying based
on exiting ConfigurationOf / BaselineOf objects, relying on the spec
if there is no registering in Metacello (kind of funky in the case of a
ConfigurationOf, since you don't know which version was effectively
loaded... so you just play guesses with the various versions available
in the project).
Yeah, bootstrapping the registration is dicey business, because you can
fall prey to the very bugs you are trying to avoid --- Metacello does a
prime registry as a project load doit when the registration code is
initially ... you might look at
MetacelloProjectRegistry>>primeRegistryFromImage:baselineClasses:prioritizeConfiguration:,
but it sounds like you are doing something very similar ...
Hum. I'm not trying to determine a version for the configurations
present in the image... and #primeRegistryFromImage seems to, and then
I seem to get errors because it selects a wrong version (at least I
got an error doing that with ConfigurationOfEpicea, set at version
7.8.p4 where it should be version 8.1.3, and Metacello fails with a
version not found).
I'll look a bit deeper to see what is happening and how to reproduce it.
It is very likely that you are running into the very type of bug that
caused me to go with the Metacello registry in the first place ... It
can be impossible for Metacello to guess the correct version of a loaded
configuration ... I'm not sure it is worth much effort to try to
characterize the problem ... better would be for Pharo to use "Metacello
new" to build the image, so that the loaded versions are registered in
the first place ...
If you insist on looking deeper:) a common cause of wrong guesses is
that the configuration specifies a project version dependency or a
version of package that is later than the versions actually loaded in
the image --- this can happen when only a partial load of the
configuration is done where those projects or packages are not actually
loaded by the configuration itself --- without the actual registration
information from the load, Metacello looks at the loaded
projects/packages and tries to match it with a version of the
configuration and this "false" dependency information causes Metacello
to look for an earlier version that matches ...
Dale
