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

Igor Stasenko siguctua at gmail.com
Mon Feb 22 15:12:09 UTC 2010


On 22 February 2010 16:11, keith <keith_hodges at yahoo.co.uk> wrote:
> 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.
>

I agree with Keith here.
The 'declarativeness' of package configs makes no sense to me. What it
can be used for?
The only thing, where it can be useful is to show us, what you may
need when browsing the package(s) on server. Or compare two different
configs? I barely see much usefullness in it. The main purpose of
package management tools is to be able to load/unload a code. The rest
is optional.

And anyways, you have to run some code to install the stuff in image,
and inevitably, have to deal with dependencies,
and different forks/dialects nuances. So, you still relying on code.
The only difference is where it written.
And this is where 'declarativeness' standing in your way. There is
virtually infinite number of preconditions, which may influence the
installation procedure. Inventing, how to scribe them down using
declarative way IMO is doomed from the very starting.
The package maintainer , who writing the configs knows what works and
where, and so, he is to decide, what installation code should do, and
what not.
So, i think, S/P is more enabling in this situation, than Metacello,
since its uses a list of instructions (tasks) - which can be anything,
not a declarative list of dependencies, which should be handled by
some uber-tool.

Sake is 'Make' - its configs is code with direct actions, not abstract
declarations. Its degree of declarativeness as high as you want to.
But you don't have to rely on some 'magic' in package-management tool
you using. If you want a highly customized install/deinstall
procedures, you are free to scribe them down. And if you installation
is simple - then why use package management at all - Installer is just
enough! :)
I think that if we take a look at SqS projects, which contains more
than 1 package to load, about 80% of them could be loaded using just
Installer.
And only 20% of them would require a more sophisticated stuff -
'package management'.
So, why selling something, which in 80% of cases is just useless? I
don't buy it :)

Building custom images is separate domain (btw, i wanna see how one
could build a custom image using just a declarative configs, i.e.
which don't contains any 'scripted' custom actions).

>> 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, may i ask you to illustrate us a use of S/P for the same
scenario, decribed by Torsten in post above?
I think it would be an interesting comparison.

> Keith
>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list