[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 17:11:33 UTC 2010


On 22 February 2010 17:47, Torsten Bergmann <astares at gmx.de> wrote:
> Take care: lengthy post.
>
> Myself wrote:
>>Your Installer code would ALWAYS load the latest of each monticello
>>package in the repo.
>
> One additional thing to note here: as a developer on a project you
> may want exactly that: not load a specific version but load the
> LATEST package versions available from a repository to be "up to date".
>
> This is easily done by loading a baseline instead of
> a released version - so you can have the same result as with an
> "installer script without versions" here.
>
> In our example if you would load '1.0-baseline' you would get the latest
> packages released before the split of the core package was done and if
> you load the '1.1-baseline' you will be up to date on the project
> (since it is the last baseline).
>
> Igor wrote:
>>You maybe missed one thing: Installer can load a specific version of
>>package(s).
>>It is an 'extra' feature which picks the latest version, but you may
>>not use it, if you don't want it.
>
> I know that - I dont say you can't do this with Installer. But think
> about the scenarios you would end up with a similar scheme:
>
>   MyConfig>>installV10Latest    -> similar to the #baseline10:
>   MyConfig>>installV10          -> the same as #version10
>   MyConfig>>installV11Latest    -> similar to the #baseline11:
>   MyConfig>>installV11          -> the same as #version11
>
> So you would end up with the same we currently have in Metacello.
>
> Metacello does just one thing more: it separates the dependency description/load
> order description (baseline) from the version of the packages the loader should use.
>
> If you do it with your Installer scheme you would have the load order coded in all your
> four #instalXXX methods. In Metacello the order is only in the two baseline methods.
>
Nope.
I am free to implement any installation which is good for me. I can
split it on 2 methods or 4..
or 10.. What makes you think that i can't reuse the code when using
installer? Hey, this is a smalltalk code after all!


>>So, please tell me again, why i should use Metacello for this?
>
> You could always write a script (using Installer, Gofer, whatever),
> but does it make sense? To automate and unify things you would have to agree on a
> few basics for the descriptions.
>
> So wouldnt it be better do describe dependencies and version to use
> in a declarative way so we could have tools to manage it.
>
> As in Linux - you could provide a shell script for the installation of your
> program OR you create a description that is usable by the package management
> system. Anybody who knows how to use "apt-get" now also knows how to get
> you package then.
>
> But here are some more arguments to at least have a look at Metacello:
>
>  a) because in any case you would end up with a similar scheme to satisfy
>     the scenarios (with Installer or any other implementation)
>

As i mentioned before 80+% of projects don't need to use multi-level
dependency tracking, because they are plain simple.
And i am still living in this 80+% niche (unless somebody will hire me
to write a BIG smalltalk project).
Then we could talk about how i end up and with what :)

>  b) because it provides a basic scheme already (depending on your own history
>     baselines and versions may be known to you)
>
>  c) because it provides a reusable format and I can describe dependencies not
>     only between Monticello packages for your own project but also
>     between Metacello configurations. So you could manage "inter-project"
>     dependencies.
>
>     This is crucial that one project can base its work on a specific milestone
>     of another. In my code I can rely on version 1.1 of MyDatabaseDriver
>     which itself relies on version 1.2 of FFI, ...
>
>     (Again: You can also do this with Installer scripts but you would have to
>     define rules people would have to follow).
>

Less rules means more freedom. More rules -> less freedom. My choice
is freedom.

>  d) While you "hard code" an Installer script the Metacello description uses
>     a "spec" object. Such a spec could be managed with tools.
>

By "hard coding" you mean referencing the 'Installer' global?
Well, i think this can be easily avoided, once it become an issue.
Installer is DSL and there's a little difference who providing it,
once this DSL implementation works out of the box.

>  e) Metacello is not Squeak specific: it already works in Glass, Pharo and
>     Squeak trunk. There is work going on on having it in older squeak releases too.
>
>     With a common PMS we could easily share and exchange code - at least the
>     one that is not bound directly to the ST system it is implemented.
>
>     A PMS should also help to manage differences here. There is some basic
>     support for that in Metacello. You could write a spec for Pharo and one for Squeak
>     if you like.
>

This is good. But i think that 99.9% of Metacello portability based on
Monticello port(s).
And so, you can say the same about Installer. It's just a single class
and i think it can be easily ported to run on any smalltalk.
There is version which been splitted on multiple classes, and also
rewritten specifically to not use any globals (except Smalltalk at: ).
So, it has zero dependencies. Which means you can load it into any
smalltalk. Of course, it may not work as expected, but this is another
story, which leads us to f).

>  f) Metacello is already MIT, there is a google project for it and it
>     is actively maintained.
>

This is a selling point. Its been maintained. The rest of arguments is
not very convincing.

>
> I dont say that Metacello solve all problem yet - but at least a few and it
> is open for new ideas. So we all should have a look at it. Nothing more!
>
>

Sure thing. But not before i grow up from my 80% niche ;)


> Keith wrote
>>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.
>
> It's obvious that the author is not able to to test in every context. Will an app
> developer for Linux test any distibution that's out there ... no. He just makes a release
> for the most common ones.
>
>>It cant be because a kernel image will not have Monticello loaded, nor
>>will it have network, or compression even.
>
> Shouldnt the kernel image have either a minimal package management system or
> at least boostrap code to load one?
>
>>[SNIP - removed lot's of "my stuff does it better" mumbling]
>
> OK, again. I still waiting for the proof that you can do better. As I said on
> the vm-dev list, show me on the Seaside/MetaSource example how to do it with your
> tool chain. I'm still open to it.
>
> Unfortunately you were not yet able to do so! If you cant explain/document or use your own
> technology to demonstrate to others how to use them then you may be a good developer
> but you waste your time since nobody will ever dive into your stuff or buy it.
>
>>I have come to the conclusion that having dependency
>>management is not the way to go
>
> No comment
>
>>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.
>
> You could not deny the fact that we need a description of existing packages, their
> dependencies and versions that fit together to make up milestones of project
> releases that can build on each other.
>
> I dont care about the internals of Metacello - you can easily unload it after
> it has it's job done. ;)
>
> We can even transform the spec descriptions into other formats, write new
> or better tools on it...
>
>
>>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,
>>
>>I now have the same opinion of Monticello
>
> There is always something better. But you cant change the whole world in one
> day. You need a pragmatic look what is already there and can be used to get the
> next job done.
>
>>I have sat starting for 4  years at horrible code in the kernel, and it is still
>>there.
>
> OK, so why dont you change it? If I remember correctly it is now possible to
> contribute to trunk. It may not be the best process - but at least it is possible.
>
> If it is too complicated since you need more access/rights whatever then show
> us how to use your ideas in Cuis and let the community decide...
>
>
> Andreas wrote:
>>we do indeed need a package management system. Urgently.
>
> +1
>
>>with the eyes of what I'd expect to see in a package *management* system
>
> I never claimed that it is finished or the best thing ever invented.
> It solves a few problems and if we all dive in a little bit we may find
> or solve all the things that need to be adressed.
>
>>What's worse, that ConfigurationOfXXX code has specific
>>dependencies on other code (Metacello) which it first loads and that
>>again has other dependencies (Gofer for example).
>
> This is just to bootstrap, the spec description is unrelated to Gofer.
>
> That the spec is defined in code is not a problem for me, since I can easily
> transform it to other formats (XML, whatever). It is one form of a description.
>
>>As far as I understand, Metacello doesn't know what it has loaded.
>
> Thats not true:
>
>  ConfigurationOfHelpSystem lastMetacelloVersionLoad
>
> You can even recreate the spec easily:
>
>  (ConfigurationOfHelpSystem project version: ConfigurationOfHelpSystem lastMetacelloVersionLoad key) spec
>
>
>>Well, there's just no support for unloading,
>
> I'm sure it will support unloading in the future. Did you see  MetacelloSpecLoader>>unload
>
>>I'm looking forward to reevaluating Metacello at this point again.
>
> That does not anymore sound like your first statement ;)
>
>
> Igor wrote:
>>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.
>
> I already asked him to reproduce "ConfigurationOfMetaSource" from
> http://www.squeaksource.com/MetaSource as an example for me
> to really compare. See [1]
>
> Anything I got was a simple response that:
>
>   "Sake/Packages does all that." and "(Package named: 'Seaside') latest load."
>
> Crazy! I dont want to offend him but he is really bad in selling his own
> stuff to others...
>
> Bye
> T.
>
> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003871.html
>
>
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list