On 04/25/2017 08:09 AM, Thierry Goubier wrote:
2017-04-25 16:11 GMT+02:00 Dale Henrichs
<[email protected]
<mailto:[email protected]>>:
[ Shortened for brevity ... ]
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 ...
Of course...
Now, I just compute the closure of all the configuration version specs
over the set of packages present in the image, by name. If a package
name is present in one of the version specs, then it is considered as
part of the project.
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 ...
Yes, this is the reason. In the case of Epicea in the latest image,
the last version is 8.1.3, but ConfigurationOfEpicea>>#currentVersion
returns 7.8p4.
7.8p4 is the highest version for which there is a dependency on the
STON project, dependency which is respected in the image (version
requested is 0.17, version present is 0.23). 7.8p4 and all higher
versions also have a dependency on Smark, which isn't loaded.
So Smark is the "culprit". Since Epicea is loaded and functioning, the
Smark project is not absolutely required, but since there is a
dependency in the Configuration Metacello doesn't know that the project
isn't strictly required ... I would be academically interested in the
dependency on Smark ... it is possible the Smark is just in the list of
projects, which makes it part of the default list ... since old-style
Metacello loads do not record the "loads list" for a project, Metacello
has to assume that the default list is loaded ... which could make Smark
required ...
Would that mean that:
- If one of the project in requirements is present in the image, then
the version is considered current (here, for 7.8p4, Ston is present,
Smark is not) if, for the packages of the project, all are present
with versions higher than the current configuration version spec?
Yes. When calculating the current version, Metacello can only assume
that the default list is loaded ... I considered "improving" the current
version calculation, but I knew that actually recording the exact
project specification that was loaded was far superior to any
complicated guessing game that I could devise for Metacello and I took
that route ... besides the current version calculation can be extremely
expensive ...
- If none of the projects in requirements are present in the image,
then the version is not considered current (in 8.1.3, Smark is not
present but I see no dependency on Ston[*]) ?
Yep ... for old-style loading ...
I have a feeling this is a strange result, and I'd prefer 8.1.3 to
have the same validity as 7.8p4.
... I prefer to record the exact project spec that is loaded ... I don't
think it is possible to create a current version algorithm that is
superior to recording the exact version that is loaded ... when it is
loaded ...
Is this MetacelloProject>>#currentVersion used to determine if a
project should be upgraded?
Yes ... Remember, we are talking old-style Metacello loading here ...
#currentVersion is only used when one does not use `Metacello new`
style loading and old-style Metacello loading has been obsolete for 4
years ...
Another question, related to the original topic: if the current
configurations in the image are in this state, is it a good idea to
leave them in? Would it have a chance of triggering incorrect updates
or suspicious errors[**] if we start using them to load Metacello
projects that depends on them?
With new style loading, if a project is not registered, then Metacello
assumes that the dependent project is not loaded at all and will proceed
to load the project version as requested ... so I don't think that any
incorrect updates should occur, but if folks have been playing fast and
loose with configurations (loading individual packages from other
projects without using a configuration or ???) then it is possible the
new style loading will load a different set of projects and packages ...
but it will do so consistently ... whereas the old-style loading could
lead to inconsistent behavior ... presumably some developers have tried
to work around the old-style loading errors by explicitly loading the
package that they want without using a configuration ... so when using
new-style loading, developers may have to "fix there configurations" ---
but then that is probably a good thing ...
Dale
