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 ...
At least, now I can easily see directly in the browser how the Pharo 6
development is moving packages inside configurations and baselines
from version to version. I'll tackle next integrating that with
Metacello, that is running project-based Metacello commands using that
project structure.
Let me know if there are any operations that you should think
could/should be included in Metacello itself ... If you are doing things
that are similar to what I'm doing in tODE, then it probably makes sense
to move the method into Metacello, so that other tool builders cna share
common code ...
Dale
Thierry
Dale
