[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
|