Keith Hodges wrote:
BTW, when I try to install Seaside in Pharo using Packages I get the following error: PackageInfo>>doesNotUnderstand: #propertyAt:put:
In a standard squeak image there are several lists of "what is currently installed", and these get out of sync quite easily. The PackageInfo and PackagesOrganizer in MC1.5/LPF aims to provide a service to other tools such as SM, Packages, and MC, keeping one master "what is installed" list.
Keith
At present Sake/Packages does keep its own list of what is installed in (Packages provided), however it tells each PackageInfo which 'Packages' entry was used to load it. This in theory allows Packages to be unloaded and to be able to reconstruct its provided list from the PackageOrganizer master list. Packages also uses this to provide Monticello wth menus for "upgrade" and "unload" from 'Sake/Packages'. S/P uses the property dictionary as follows.... #addToPackageInfo " Here we tell the PackageInfo instance what name was used to load it. if a package appears in PackageInfo under a different name to which it appears in Packages, the PackageInfo name can be told to us via metadata #mcName: Example: 'Seaside' is in PackageInfo as 'Seaside2'. " I have changed this code to only use propertyAt:put on PackageInfo if it is there. Keith p.s. One of the goals of LPF for all images is to provide a platform that enables new code NOT to have to be backwardly compatible since LPF can take up the slack. I find it ironic that Pharo is suffering from backward compataibility issues, and I have to put "respondsTo:" just to cover pharo's back.