[squeak-dev] Re: Why a package management system (Was: Re: Help system now for Squeak and Pharo)

keith keith_hodges at yahoo.co.uk
Mon Feb 22 14:11:30 UTC 2010


Andreas,

you don't ask for much do you!

Lets consider your questions with respect to Sake/Packages

> My problem with Metacello today comes from that I've been looking at  
> Metacello with the eyes of what I'd expect to see in a package  
> *management* system, namely:
>
> a) The ability to declare packages and dependencies

In S/P the package definition is just a SakeTask carrying around with  
it arbitrary metadata, and so are any dependencies, so when you  
instantiate the Seaside loading task

(Package named: 'Seaside')

You simply get the hierarchy of tasks to do or consider doing.

You can then walk this hierarchy and use it to perform actions.  Apart  
from the default load action, and notably the unload action, you could  
also have an action which walks the hierarchy and uses the metadata  
generate an install script which could be fed on the command line to  
an image. This script generating idea was a future plan for bob to be  
able to build an image without needing any tools in the target image.

> b) The ability to install packages

Our default task, #load uses the url field from the metadata.

Typically we delegate this to the simplest option that "knows" how to  
install things any which way - Installer.

Installer works out from the url that it is an MC package and where it  
comes from etc.

To make Sake/Package equivalent to Metacello imhm, the only addition  
needed would be to add a #urls field to the metadata so that one  
definition can install multiple packages rather than just one (as it  
is at present).

> c) The ability to reflect about package

This is provided in, the "provided list", and in the fact that  
packages are just tasks, so a task can add an if clause, such as "if  
this class is absent from the system then this task should be applied  
(or not)."

> d) The ability to uninstall packages

S/P has an unload action, it takes the current package and looks at  
all the packages that are loaded to see if any of these depend on the  
package to be unloaded, it uses this to determine an unload order.

> If you look at the above criteria, then Metacello *today* only  
> really supports one of these four criteria:
>
> a) The declarative nature of packages and dependencies is violated  
> because Metacello requires to store and run code to create a package  
> spec.

S/P stores the package definitions as methods, that can (in theory) be  
loaded even if Sake/Packages is not loaded. The methods themselves do  
not require S/P. The method is just a convenient database.

I don't accept this distinction between declarative definitions and  
code definitions, its just the same distinction as objects versus  
files. XML may be declarative, but you need the XML reader to make any  
sense of it, you still have data and behavior working in combination  
to get anything done. Objects, i.e. code are better, and you can code  
in a manner that requires lots of things and you can code in a manner  
which doesn't.

S/P has one dependency to use the Metadata, SakeInfo, a simple  
dictionary where #somefield: is equivalent to at: #somefield put:  
value thanks to #doesNotUnderstand. Its hardly a huge deal to have one  
extra method on a subclass of dictionary to enable a metadata format  
in code, whereas an XML so called declarative definition comes with  
packages upon packages of extra stuff, just to make use of it.

> c) As far as I understand, Metacello doesn't know what it has loaded.

S/P did know what was loaded, and we were aiming to merge the  
PackageOrganiser list of what is loaded with MC list and the S/P list,  
so that PackageOrganiser holds the master collection on behalf of the  
other tools.

> I don't think there is a way to ask Metacello "please show me  
> everything I have loaded" or "uhm, which version of HelpSystem did I  
> load? was that version 1.0 or 1.1 or what?".

In S/P

Packages provided.

> If I'm not mistaken there is also no notion of a "provided" package  
> that doesn't directly correspond to MC package granularity, for  
> example knowing that loading FFI-ar.10.mcz provides the same code  
> that's in FFI-Pools-ar.1.mcz, FFI-Kernel-2.mcz, and so on. (there  
> are many variants on this topic for example the difference between  
> the Shout release and ShoutCore we have in trunk etc)

I know it is cheating, but at the package granuarlity MC does this for  
you. If you try and load a Shout-release and and Shout-Core that are  
in actual fact the same, nothing will happen when you load the second  
package, because MC only loads the changes between the current system  
and the package you are loading. So you could add some reporting to  
your load and be told "when I loaded this package only 3 methods were  
really any different."

> So of the four corner stones of a package *management* system, the  
> only thing that's really working today in Metacello is the part that  
> installs packages. Which is exactly why Metacello today looks a lot  
> like a glorified version of Installer :-)

S/P isnt just a glorified version of Installer. It delegates to  
Installer things that Installer does well. It on the other hand "just"  
provides for metadata and dependencies, and some algorithms that can  
use them (like unload). It isnt trying to be an all singing all  
dancing package manager. It's primary goal was a) a replacement for  
universe that can be edited by users b) the collection of what works  
where data for multiple forks (an that isnt going to happen any time  
soon) and c) installer with dependencies.

The difference in ethos is that S/P and Installer aim to be simple  
tools used in powerful combinations, neither of which is simple enough  
in my current thinking.Whereas Metacello is aiming to be a  
comprehensive no holds barred package manager for which complexity and  
verboseness is no obstacle.

Keith







More information about the Squeak-dev mailing list