In MCMcmUpdater, the UpdateMapName is initialized from a preference. This is 'update.spur' for the Spur image, and 'update' otherwise. This supports the parallel update streams for Spur and non-Spur images.
A side effect is that certain packages (e.g. head branch for OSProcess) cannot be loaded from SqueakMap because the loader does this:
MCMcmUpdater updateFromRepositories: #('http://www.squeaksource.com/OSProcess')
which does not work when UpdateMapName is set to 'update.spur' because the OSProcess repository has only update maps named 'update' (and there would be no difference between Spur and non-Spur anyway).
MCMcmUpdater is a collection of class-side methods, and this is making me think that it may be time to have it be instance based, so that different updaters (one for OSProcess, another for Squeak trunk) could know what update map files to look for.
I am not entirely clear on how the update stream (or streams?) for trunk will work after we move to the Spur image in 5.0/4.6, but it seems desirable that an external package (OSProcess, VMMaker, others) should be able to specify the name of its own update maps independent of the Squeak trunk update preferences.
How should this work? Does it make sense to move the logic for MCMcmUpdater into instance side methods so that more than one instance of MCMcmUpdater can exist?
Or maybe it is sufficient to find a way to implement this:
MCMcmUpdater class>>updateFromRepositories:updateMapName:
so that a SqueakMap package loader could override the default preferences for trunk?
Dave
On Tue, Apr 28, 2015 at 10:32 PM, David T. Lewis lewis@mail.msen.com wrote:
In MCMcmUpdater, the UpdateMapName is initialized from a preference. This is 'update.spur' for the Spur image, and 'update' otherwise. This supports the parallel update streams for Spur and non-Spur images.
A side effect is that certain packages (e.g. head branch for OSProcess) cannot be loaded from SqueakMap because the loader does this:
MCMcmUpdater updateFromRepositories: #('http://www.squeaksource.com/OSProcess')
which does not work when UpdateMapName is set to 'update.spur' because the OSProcess repository has only update maps named 'update' (and there would be no difference between Spur and non-Spur anyway).
Hmm, this bug is a show-stopper for the release; no one will be able to load "head" versions of any packages into Spur..
MCMcmUpdater is a collection of class-side methods, and this is making me think that it may be time to have it be instance based, so that different updaters (one for OSProcess, another for Squeak trunk) could know what update map files to look for.
Sounds reasonable.
I am not entirely clear on how the update stream (or streams?) for trunk will work after we move to the Spur image in 5.0/4.6, but it seems desirable that an external package (OSProcess, VMMaker, others) should be able to specify the name of its own update maps independent of the Squeak trunk update preferences.
+1
How should this work? Does it make sense to move the logic for MCMcmUpdater into instance side methods so that more than one instance of MCMcmUpdater can exist?
That might lead to a solution. Would be nice if we could find a simpler way to hack our way out of this since we're so close to the release..
Or maybe it is sufficient to find a way to implement this:
MCMcmUpdater class>>updateFromRepositories:updateMapName:
so that a SqueakMap package loader could override the default preferences for trunk?
Yes, that would be another option.
And, yet another, is the newer ability by Installer to #merge: packages. So, for your "head" release of OSProcess, you could change it to:
Installer new merge: #osProcess
However, this just avoids the problem rather than solves it. We should solve it..
But these issues should go away one we migrate trunk to the spur branch ? Another big change like that is not yet on the horizon as far as I know.
Karl
On Wed, Apr 29, 2015 at 6:11 PM, Chris Muller asqueaker@gmail.com wrote:
On Tue, Apr 28, 2015 at 10:32 PM, David T. Lewis lewis@mail.msen.com wrote:
In MCMcmUpdater, the UpdateMapName is initialized from a preference. This is 'update.spur' for the Spur image, and 'update' otherwise. This
supports
the parallel update streams for Spur and non-Spur images.
A side effect is that certain packages (e.g. head branch for OSProcess) cannot be loaded from SqueakMap because the loader does this:
MCMcmUpdater updateFromRepositories: #('
http://www.squeaksource.com/OSProcess')
which does not work when UpdateMapName is set to 'update.spur' because
the
OSProcess repository has only update maps named 'update' (and there
would be
no difference between Spur and non-Spur anyway).
Hmm, this bug is a show-stopper for the release; no one will be able to load "head" versions of any packages into Spur..
MCMcmUpdater is a collection of class-side methods, and this is making me think that it may be time to have it be instance based, so that different updaters (one for OSProcess, another for Squeak trunk) could know what
update
map files to look for.
Sounds reasonable.
I am not entirely clear on how the update stream (or streams?) for trunk will work after we move to the Spur image in 5.0/4.6, but it seems
desirable
that an external package (OSProcess, VMMaker, others) should be able to specify the name of its own update maps independent of the Squeak trunk update preferences.
+1
How should this work? Does it make sense to move the logic for
MCMcmUpdater
into instance side methods so that more than one instance of MCMcmUpdater can exist?
That might lead to a solution. Would be nice if we could find a simpler way to hack our way out of this since we're so close to the release..
Or maybe it is sufficient to find a way to implement this:
MCMcmUpdater class>>updateFromRepositories:updateMapName:
so that a SqueakMap package loader could override the default preferences for trunk?
Yes, that would be another option.
And, yet another, is the newer ability by Installer to #merge: packages. So, for your "head" release of OSProcess, you could change it to:
Installer new merge: #osProcess
However, this just avoids the problem rather than solves it. We should solve it..
On Wed, Apr 29, 2015 at 12:14 PM, karl ramberg karlramberg@gmail.com wrote:
But these issues should go away one we migrate trunk to the spur branch ? Another big change like that is not yet on the horizon as far as I know.
Yeah, that's true. This does fit because the "head" versions in SqueakMap just mean for the current version of Squeak. They will automatically "transition" to Spur when we merge the branch. Fixed versions of OSProcess and other apps will still be available for 4.x versions of Squeak, presumably anyone following the head release would want to use Squeak 5.x.
squeak-dev@lists.squeakfoundation.org