[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.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|