[squeak-dev] Why a package management system (Was: Re: Help
system now for Squeak and Pharo)
keith
keith_hodges at yahoo.co.uk
Mon Feb 22 04:39:00 UTC 2010
> By using Metacello a projects author can make specific versions/
> package configurations available to others and afterwards commit new
> code to the repo without affection others.
The author will not have tried and tested the code in every context,
so really he doesn't know what is actually needed to load. The
definitions need to be done the other way around, in the hands of the
"users" to tell the author what works where, and what fixes are needed
for what to work where.
I am looking forward to more forks, the way metacello manages its
package definitions will not scale to more forks, it is cluttered
enough as it is anyway and you only have 3 forks. What about when we
are up to 50 or so forks.
You keep saying you only need this only this and only need that, this
is way too complicated, and you only have to have 15 things loaded,
before it all works. Yet you are telling us that this is the way
forward for a modular future built on a kernel image.
It cant be because a kernel image will not have Monticello loaded, nor
will it have network, or compression even.
The original 2006 Installer vision did get lot of bang for one little
buck. Installer was one class, and it was only ever intended to be the
first class. It only takes one more class to add dependencies
(SakeTask) and one more to add all the metadata you could want
(SakeInfo).
Installer has the advantage that you can see exactly what it is
installing, and you can pick a single line of code and execute it line
by line as you go for debugging. You can also call up specific
versions, or authors, and you can also load stuff from squeakmap
without squeakmap loaded, and load MC packages without MC loaded. You
can point Installer at a web page and it finds the script, it does
lots of things Metacello doesnt do in a more minimal context. Yet even
Installer is too complicated, you cant rely on images to have
installer loaded either!
What "we" need is for the package manager to be generating something
that is deterministic and reliable, so you can see what it is going to
do and what it did. Then mix and match stuff around, to create
localised alternative selection.
After working with Sake/Packages (which as you know is much simpler
than Metacello) but none the less capable, and it included all of
universes, I have come to the conclusion that having dependency
management is not the way to go. Sure it is flash when it works, but
when it doesn't, who knows what happened in which order. I never got
on very well with the linux apt-get stuff either.
The way I coped with linux's apt get stuff was simple, I didn't
bother, I used the knoppix distro, which comes with everything pre-
installed. This is what I think the way forward for kernel cuis is.
You distribute images with everything interesting pre-installed.
However the users can by seeing the exact organisation of how the
image was created, the user can grab the bits he wants and assemble
his image using bits of other images. So the seaside bits published in
a Seaside one click image would be grabbable, and combinable with the
bits from a Magma image, to make a Seaside-Magma image.
>> This installs in a fraction of the time and space.
>
> Hey, installer is just a loader.
You can see exactly what it is doing.
SakePackages loaded Seaside and Magma and Seaside-MagmaHelper in one
hit too, but people didn't care that much about dependency management
then, and I was building images with 60+ package in it. I have got
20+ packages just for my own framework on top of seaside... Keeping
package definitions up to date will end up as a full time job for
someone, this has got way out of hand!
My new solution is based on 3 classes, an Export Target, an Exporter
and an Export definition.
(Export to: 'testing') purge fileOut.
Is all I need to do to save everything. Why didnt I have this solution
three years ago... simply because everything we are using is too darn
complicated, and we are so convinced we have some great tools that we
aren't bothering to think of simpler ideas.
> Metacello is a package management
> system!!!
Big, complicated, lots of dependencies.
> Ever worked with Envy or Maven in Java, ...?
No.
> Without Metacello (or a comparable package management system) we
> will NEVER SCALE projects or allow that they develop independent
> from each other without breaking each other!
I disagree, I think you just need to think about the problem in
simpler terms.
> Especially when
> they are managed outside of the image - and I think that's our goal:
> a small kernel image and external projects/packages that could be
> loaded (and that fit together to work and could be based on another).
>
> Metacello does the minimal thing to manage that and even if it
No way does Metacello represent a minimal thing
> may require more work (especially on tools) it does a fairly good job
> already. You just have to learn about it and about modularity.
>
> Sorry for the long post - but I hope I was able to wet your appetite
> towards modular Smalltalk.
You just scared me, a poor mediocre coder, imagining a future when the
loading tools have more code and classes in them than the system itself.
I think that Juan has it right, simplicity, elegance and the ability
to innovate and use ingenuity is the key to solving our future
problems including scaling.
The problem I see as a casual observer looking at metacello is that
if that is our "simple solution" and it doesn't do quite what I want,
then I am not going to be able to fix it. I prefer the small tools
combine to make powerful solutions.
I now have the same opinion of Monticello. Everyone is so busy using
the package version control that they have given up trying to find
other simpler solutions to the real problems.
A week of working in an image without Monticello and I am rocking!
At the end of the day squeak was sold as an environment that anyone
could change right down to the metal. However we still rely on
"someone else" to fix the kernel for us. I have sat starting for 4
years at horrible code in the kernel, and it is still there. Honestly
I think Juan has shown us the light
Keith
More information about the Squeak-dev
mailing list
|