Package Universes and Squeakmap
Keith Hodges
keith_hodges at yahoo.co.uk
Thu Jul 26 15:19:50 UTC 2007
I have been using package universes for a few days, and have discovered
some of its limitations. I have also been wondering how best to
integrate its use with SqueakMap.
We already have SqueakMap as the master repository and Lex, the creator
of package universes does not seem to think that simply tagging items in
SqueakMap according to what works with what and what doesnt would work
very well, all things considered. To a certain extent I now agree with him.
I initially thought that having Universes separate from SqueakMap was a
bad idea. However, after using universes I have now changed my mind and
think that is a good idea. I imagine SqueakMap to be the Model, and
Universes to be the View, with the community acting as the controller so
to speak.
One of the limitations of Universes is that it does not have much in the
way of integration with Squeakmap or Monticello, and so it looks to be
attempting to make SqueakMap obsolete, but it is somewhat of a poor
replacement. At present it is totally agnostic to the package provider,
it simply loads a package from a url based upon the file's extension.
One of the positive things about SqueakMap is that it caches the
packages, it also has more information on it than the universe. I think
that it too would benefit from some feedback features, and more
openness, and some indication of dependencies, but perhaps it makes
sense not to have these as hard and fast rules. For example, Seaside
specifies Kom, but some users may prefer Swazoo. This flexibility seems
difficult to support prescriptively on the macro level, but could be
supported in local mini/sub-universes, such as a "Swazoo users seaside
universe".
Perhaps SqueakMap could allow anyone to upload a new version, but
reserve "blessing" of releases to the owner/maintainers, since this is
how a public squeaksource repository works by "social" default.
One Universe limitation is that when using a Universe package, unlike an
installer script which integrates with the native monticello tools, the
package is loaded, but the Monticello browser is not informed of the
repository details.
This means that you have to manually inform the Monticello Browser of
the required repository before a monticello package with dependencies
referred to in a package universe will work. For example when Chris
posted 'Magma Server' he would have had the Monticello Browser properly
configured on posting the package to the Universe and it will work for
him but it will not work for users out of the box who do not have the
Monticello repositories configured.
So thinking about it this it would not be a problem at all if Package
Universes replaced:
http://www.squeaksource.com/Magma/MagmaServerLoader-cmm.25.mcz
with:
Installer squeaksource project: 'MagmaTester'; install:
'MagmaServerLoader-cmm.25'.
So why not have Package Universes call installer for SqueakMap items too.
Installer squeakmap install: 'MyPackage(1.0)'.
(I will fix installer to fall back onto using the http interface
#websqueakmap if SMSPackageLoader is not present)
By doing this we can uphold the use of SqueakMap as the place to publish
released packages, with Universes being the place to define dependencies
within a locally defined context/scope/use scenarios.
If the "publish to squeakmap" button could be fixed on squeaksource the
picture would be complete.
This approach also allows mantis fixes and change sets to be included in
the Universes without any extra work.
thoughts feedback?
best regards
Keith
I think that having universes, together with sub-universes and
personal-local universes
More information about the Squeak-dev
mailing list
|