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

Andreas Raab andreas.raab at gmx.de
Mon Feb 22 17:20:05 UTC 2010

Igor Stasenko wrote:
> I agree with Keith here.

And I disagree :-)

> The 'declarativeness' of package configs makes no sense to me. What it
> can be used for?

Ensure that it can be understood many years from now. Simple as that. 
Look at your ConfigurationsOfXXX. Assume that twenty years from now 
someone is trying to load one of them. What's going to happen? It will 
try to find stuff on Lukas' site (Gofer) it will try to find stuff on 
Gemstone's site (Metacello) and those sites may long be gone.

Now you're back to reading what's in it. Look at ConfigurationOfXXX. I 
know my Squeak pretty well, but that stuff is gobbly gook to me. I can't 
make sense of half of it. Installer is better in this regard but these 
things always end up with more convenience stuff which causes more 
complexity and will make it harder if not impossible to read 20 years 
from now.

Compare this with a simple alternative (I'm not using XML because of the 
knee-jerk reaction to XML in this community):

[Disclaimer: Please folks, don't come back and give this "oh but it 
doesn't do x,y,z" response that I can see coming at me. This is NOT an 
actual package spec, this is an example for what a simple package spec 
*might look like*]

Package: HelpSystem-Core
Version: 1.0
Repository: http://www.squeaksource.com/HelpSystem
Installs: HelpSystem-Core-tbn.1.mcz
Installs: HelpSystem-Tests-tbn.1.mcz

Package: HelpSystem
Version: 1.0
IntendedPlatform: Squeak
IntendedVersion: 3.10
Requires: HelpSystem-Core
Repository: http://www.squeaksource.com/HelpSystem
Installs: Squeak-Project-Help.1.mcz

Package: HelpSystem
Version: 1.0
IntendedPlatform: Pharo
IntendedVersion: 1.0
Requires: HelpSystem-Core
Repository: http://www.squeaksource.com/HelpSystem
Installs: Pharo-Project-Help.1.mcz

Package: HelpSystem
Version: 1.1
IntendedPlatform: Squeak
IntendedVersion: 4.0
Requires: HelpSystem-Core
Repository: http://www.squeaksource.com/HelpSystem
Installs: Squeak-Project-Help-tbn.4.mcz

You can *read this and understand what it means*. You can fully document 
it in about fifteen minutes. You can write a parser that reads such 
definitions in five minutes (two if you'd be using XML because you'd 
have the parser already). And you *won't* be trying to add "convenience 
functions" because you're not programming *in it* but rather write 
interfaces that deal with it.

The thing that's by far the most screwed up about Metacello is that in 
practice the ConfigurationsOfXXX are used as input, instead as generator 
of the proper specs. Nobody will be able to load one of these 
ConfigurationsOfXXX twenty years from now. The sites will have changed, 
the code will have changed, the interfaces will have changed. Assuming 
that this code will load twenty years from now is *incredibly* naive. 
Assuming that a simple format like the above can survive essentially 
unchanged is not.

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

Obviously loading and unloading are crucial parts, but so is having the 
ability for the package management system to describe what you've 
loaded. In business, not being able to go back and say "gee, they're 
running version X.Y.Z over there, was the bug #3912 fixed in this 
version?" will kill you.

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

In practice, the difference will be that your installer code will have 
additional dependencies that you're not aware off until it's too late. 
Could be simple stuff like using {} or #[] syntax. Oops, can't load 
*that* into Squeak 2.1 any longer. Or what if we require static typing 
in Visual Squeak++ 6.0? That's why these things are "specs", so that 
they are fully documented and understood and *not* randomly extended for 
convenience or otherwise.

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

I'm sorry but you're confusing issues here. There is no relationship 
between declarative specs and whether a package spec is written by the 
package maintainer or a third party. I'm fully in favor of having 
maintainers write those specs, but they can do that either way.

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

Ouch! Depedency-driven build systems are not even remotely the same as 
configurations. Please don't compare the two. A dependency driven task 
system can almost certainly be used by a package management system, but 
the reverse is simply not true. The configuration describes the intended 
end state, the task system can help achieve the end state. So you can 
instruct the task system to load the proper entities (in fact, that's 
exactly what my builds script did) but you can't ask that task system 
what package versions it has loaded since it probably doesn't even know 
about that concept explicitly (at least not if the system is well-factored).

> 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! :)

Sure, if you don't need package management, there is no point in using 
it. However, that's a false premise - there are enough people (incl. 
myself) who *desperately* want one.

> 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 :)

Or perhaps you're confusing cause and effect. The fact that we're unable 
to describe package dependencies in proper ways leads to the inability 
to actually rely on anything found in the various places. Why don't 
people use Squeakmap any longer? It served its purpose, then it started 
rotting because it didn't address several issues a package management 
system needs to address. Ditto with Universes (just a different set of 
issues). They all serve certain purposes but they all have failed to 
provide a reliable, long-term solution to package management in Squeak.

I am pessimistic (and consequently quite hesitant in adopting it) in 
just the same way about Metacello. These issues don't apply to 
Installer, Sake or S/P for the reasons outlined above, but then these 
don't address the same set of issues.

    - Andreas

More information about the Squeak-dev mailing list