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