Why a package management system (Was: Re: Help system now for Squeak and Pharo)

> Andreas Raab wrote:
>> BTW, for people who'd like to install HelpSystem with Installer instead
>> of Metacello, use this:
>>
>
> NOOOO!!!!!
>
> As Yanni already answered to you: the Metacello code would load version '1.0' of the help system -
> so it loads a A CLEARLY DEFINED MILESTONE with packages that are intended to
> work together and which is also intended by the author for others to use.
>
> If I later define a '1.1' or '1.2' milestone any user could decide if he is
> ready to adapt his own code (if it is based on my project) to my new
> releases or if he (for whatever reasons) continues with one of my old releases, like 1.0.
>
> Your Installer code would ALWAYS load the latest of each monticello
> package in the repo. So depending on the time you run it (and the state
> of the repo) you get DIFFERENT results and may break code. Thats horrible!
>

> 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.
>
>> This installs in a fraction of the time and space.
>
> Hey, installer is just a loader. Metacello is a package management
> system!!! Ever worked with Envy or Maven in Java, ...?
>
> 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! 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
> may require more work (especially on tools) it does a fairly good job
> already. You just have to learn about it and about modularity.
>
>
> Think of the following scenario:

>
> Sorry for the long post - but I hope I was able to wet your appetite towards modular Smalltalk.
>
> Bye
> T.
>
> [1] https://docs.sonatype.org/download/attachments/1999021/pom-dependency-graph.png?version=1&modificationDate=1212678465631
>
> --
> NEU: Mit GMX DSL über 1000,- ¿ sparen!
> http://portal.gmx.net/de/go/dsl02
>
>

> On 22 February 2010 02:02, Torsten Bergmann <[hidden email]> wrote:
> > Andreas Raab wrote:
> >> BTW, for people who'd like to install HelpSystem with Installer instead
> >> of Metacello, use this:
> >>
> >
> > NOOOO!!!!!
> >
> > As Yanni already answered to you: the Metacello code would load version '1.0' of the help system -
> > so it loads a A CLEARLY DEFINED MILESTONE with packages that are intended to
> > work together and which is also intended by the author for others to use.
> >
> > If I later define a '1.1' or '1.2' milestone any user could decide if he is
> > ready to adapt his own code (if it is based on my project) to my new
> > releases or if he (for whatever reasons) continues with one of my old releases, like 1.0.
> >
> > Your Installer code would ALWAYS load the latest of each monticello
> > package in the repo. So depending on the time you run it (and the state
> > of the repo) you get DIFFERENT results and may break code. Thats horrible!
> >
>
> 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.

>
>
> > 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.
> >
> >> This installs in a fraction of the time and space.
> >
> > Hey, installer is just a loader. Metacello is a package management
> > system!!! Ever worked with Envy or Maven in Java, ...?
> >
> > 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! 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
> > may require more work (especially on tools) it does a fairly good job
> > already. You just have to learn about it and about modularity.
> >
> >
> > Think of the following scenario:
> [snip]
>
> Strange thing but with Installer i could implement same scenario(s).
> So, in same way, one could implement
>
> MyConfig>>installV10
> MyConfig>>installV11
> etc
> and inside of these methods, put a code which loads specific versions
> of packages.
>
> So, please tell me again, why i should use Metacello for this?
>

> >
> > Sorry for the long post - but I hope I was able to wet your appetite towards modular Smalltalk.
> >
> > Bye
> > T.
> >
> > [1] https://docs.sonatype.org/download/attachments/1999021/pom-dependency-graph.png?version=1&modificationDate=1212678465631
> >
> > --
> > NEU: Mit GMX DSL über 1000,- ¿ sparen!
> > http://portal.gmx.net/de/go/dsl02
> >
> >
>
>
>

> As Yanni already answered to you: the Metacello code would load version '1.0' of the help system -
> so it loads a A CLEARLY DEFINED MILESTONE with packages that are intended to
> work together and which is also intended by the author for others to use.
>
> If I later define a '1.1' or '1.2' milestone any user could decide if he is
> ready to adapt his own code (if it is based on my project) to my new
> releases or if he (for whatever reasons) continues with one of my old releases, like 1.0.
>
> Your Installer code would ALWAYS load the latest of each monticello
> package in the repo. So depending on the time you run it (and the state
> of the repo) you get DIFFERENT results and may break code. Thats horrible!
>
> 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.
>
>> This installs in a fraction of the time and space.
>
> Hey, installer is just a loader. Metacello is a package management
> system!!! Ever worked with Envy or Maven in Java, ...?  
>
> 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! 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
> may require more work (especially on tools) it does a fairly good job
> already. You just have to learn about it and about modularity.
>
>
> Think of the following scenario:
> ================================
>
>  There is a project "MyDatabaseDriver" done by Mr. Bean. He creates
>  two Monticello packages:
>
>      MyDatabaseDriver-Core-bean.3.mcz
>      MyDatabaseDriver-Tests-bean.1.mcz
>          
> Since his initial implementation (even after three commits for the
> core) seems good enough, he will create a first milestone/version for others to use.
>
> He could have written an InstallScript ... but he knows about
> the advantages of a package management system and therefore
> takes the 5 minutes tutorial to learn about Metacello.
>
> He creates a class "ConfigurationOfMyDatabaseDriver" since he learned
> that Metacello uses a simple class with methods to describe the load order
> and version of the packages that fit together. (Java's Maven for instance
> uses XML files, so called POM's).
>
>
> First Mr. Bean describes a baseline, which is nothing then the
> structure and dependencies (load order) of the packages. In our Metacello example
> this is simple done by defining a method on the projects configuration
> class (which is ConfigurationOfMyDatabaseDriver):
>
>     baseline10: spec
> <version: '1.0-baseline'>
>         spec for: #common do: [
>    spec
>                 blessing: #baseline;
>                 repository: 'http://www.squeaksource.com/MyDatabaseDriver';
>             spec
> package: 'MyDatabaseDriver-Core'.
>    spec
>                 package: 'MyDatabaseDriver-Tests' with: [spec requires: 'MyDatabaseDriver-Core'].              
> ].
>
> (*Side Note: you could chain any message to spec to be more compact here - but this example
>             is intended for readability).
>
> Anything Mr Bean has done in his first baseline method is to describe in a declarative way that he
> has two packages in an own repository - where the second one (the tests) require the actual
> code to run. So the test code is dependent on the code he tests.
>
> He also desribes the version of these Monticello packages that are know to work
> together in a second method to define a first milestone (also "Metacello version 1.0" or
> "version 1.0 of the MyDatabaseDriver project"):
>
>     version10: spec
> <version: '1.0' imports: #('1.0-baseline')>
>
> spec for: #common do: [
> spec blessing: #release.
> spec author: 'Mr. Bean'.
> spec description: 'First release 1.0 of this project '.
>                 spec
>                     package: 'MyDatabaseDriver-Core' with: 'MyDatabaseDriver-Core-bean.3';
>    package: 'MyDatabaseDriver-Tests' with: 'MyDatabaseDriver-Tests-bean.1';
> ].
>
> Since he wanted to share it he put his new configuration class "ConfigurationOfMyDatabaseDriver"
> in a Monticello package with the same name and uploads it to "http://squeaksource.com/MetacelloRepository"
>
> He now announces it on the developer list and tell other to load the project by getting the package
> (either manual, using Gofer or Installer) and then evaluating:
>
>    (ConfigurationOfMyDatabaseDriver project version: '1.0') load
>
> Hey - cool. Another developer (Mr. Frog) responded friendly on the mailinglist, told Mr. Bean
> that he found a bug and wanted to help with the project since he also knows how to fix this bug.
> He was added as a new developer on http://www.squeaksource.com/MyDatabaseDriver by Mr. Bean
> and he created two new versions of the Monticello packages:
>
>      MyDatabaseDriver-Core-frog.4.mcz
>      MyDatabaseDriver-Tests-frog.2.mcz
>
> Time to share this new milestone again, so Mr. Bean adapted the "ConfigurationOfMyDatabaseDriver" with a
> new method for the new version of the whole project 1.1:
>
>   version11: spec
> <version: '1.1' imports: #('1.0-baseline')>
>
> spec for: #common do: [
> spec blessing: #release.
> spec author: 'Mr. Bean'.
> spec description: 'New release 1.1 of this project done with the Help of Mr. Frog'.
>                 spec
>                     package: 'MyDatabaseDriver-Core' with: 'MyDatabaseDriver-Core-frog.4';
>    package: 'MyDatabaseDriver-Tests' with: 'MyDatabaseDriver-Tests-frog.2';
> ].
>
> Since the load order has'nt changed he just has to tell which new Monticello packages make up
> the new release.
>
> He uploaded this change to Squeaksource and anyone is able to load the new version with the fix:
>
>    (ConfigurationOfMyDatabaseDriver project version: '1.1') load
>
> Cool. But even the old configuration 1.0 is still loadable (if one requires it):
>
>    (ConfigurationOfMyDatabaseDriver project version: '1.0') load  
>
> No magic - but very very helpful! Think of a company who created an image for a customer
> based on the initial version 1.0 of the driver. If they have to rebuild this image exactly the
> same as it was - no problem with a package management system they are able to load version 1.0 even
> after some years.
>
>
> OK - let's go ahead. Mr. Bean and Mr. Frog are now continue to work and since the core
> is growing they want to split this package. They also use a database which allows for
> standard SQL like stuff as well as database specific stuff. Another reason to split the core.
>
> So they split the "Core" package into a "Core-SQL" and "Core-NonStandard", and
> end up with three packages now:
>
>   MyDatabaseDriver-Core-SQL-bean.1.mcz
>   MyDatabaseDriver-Core-NonStandard-frog.1.mcz
>   MyDatabaseDriver-Tests-frog.3.mcz
>
> Time for them to make a new new milestone 1.2 for the project. With the new packages
> they have to define a new baseline which is easily done:
>
>   baseline12: spec
> <version: '1.2-baseline'>
>         spec for: #common do: [
>    spec
>                 blessing: #baseline;
>                 repository: 'http://www.squeaksource.com/MyDatabaseDriver';
>             spec
> package: 'MyDatabaseDriver-Core-SQL'.
>             spec
> package: 'MyDatabaseDriver-Core-NonStandard'.              
>    spec
>                 package: 'MyDatabaseDriver-Tests' with: [spec requires: #('MyDatabaseDriver-Core-SQL' 'MyDatabaseDriver-Core-NonStandard')].              
> ].
>
> Note that the test package is not splitted - and now require both new core packages as prerequisite.
>
> And a new version for the project (now based on the second baseline) is made accordingly:
>
>    version12: spec
> <version: '1.2' imports: #('1.2-baseline')>
>
> spec for: #common do: [
> spec blessing: #release.
> spec author: 'Mr. Frog'.
> spec description: 'New release 1.2 with improvements and separate standard SQL from database specific'.
>                 spec
>                     package: 'MyDatabaseDriver-Core-SQL' with: 'MyDatabaseDriver-Core--SQL-bean.1';
>                     package: 'MyDatabaseDriver-Core-NonStandard' with: 'MyDatabaseDriver-Core-NonStandard-frog.1';
>    package: 'MyDatabaseDriver-Tests' with: 'MyDatabaseDriver-Tests-frog.3';
> ].
>
> Again they write a mail to the developer list.
>>From the users point of view nothing really changed to get the new project version:
>
>    (ConfigurationOfMyDatabaseDriver project version: '1.2') load
>
> And again: you still can load the old versions "1.0" and '1.1' using the configuration.
>
> So if have an app with code that still uses version 1.1. of the database driver you are able to do so -
> if you find the time to adapt your code to all the new changes from Mr. Bean and Mr. Frog
> you can already switch to version 1.2.
>  
>
> *Also note that the old "MyDatabaseDriver-Core-frog.4.mcz" is not removed from the
>  repository so that version 1.0 and 1.1. are still working.
>
> This is only a short introduction of what you can do with Metacello. As a package management
> system it allows you to declare/load/share defined points of your development independent
> from time. It is also a UNIFORM WAY TO EXCHANGE VERSIONS or BASE THE VERSION OF ONE
> PROJECT ON SPECIFIC VERSIONS OF ANOTHER PROJECT.
>
> If you want to do professional and reproducable development using such a system is essential!
>
> It's also a new way of communication, if you for instance want to know which version
> of "KomHttpServer" is the latest stable just check out "ConfigurationOfKomHttpServer"
> in http://squeaksource.com/MetacelloRepository and you will easily find out once you
> have understood the simple basics of Metacello.
>
>
> If you want to learn more on Metacello just
>
>    - read http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-for-monticello/
>      (outdated, but gives an overview of the goals)
>
>    - then read http://gemstonesoup.wordpress.com/2009/10/14/a-shiny-new-api-for-metacello/
>
>    - browse the text and examples in the metacello tutorial:
>
>        ConfigurationOfMetacello project latestVersion load: 'Metacello-Tutorial'.
>
>    - read http://code.google.com/p/metacello
>
> Or check out the various configurations already available at http://squeaksource.com/MetacelloRepository
> (start with simple ones like ConfigurationOfVistaCursors, ConfigurationOfScriptManager and
>  then look at ConfigurationOfVMMaker, ConfigurationOfSQLite3, or ConfigurationOfSeaside30.
>
> If you want to see how you can even automate image building of a whole seaside application
> using Metacello check out http://astares.blogspot.com/2010/01/pharo-10-release-candidate-2-and-image.html
>
> Metacello is not yet complete - but usable. Hope it will evolve -
> especially in the tools space. Look at Java where you can even
> visually browse the dependencies [1] and find cycles and conflicts, ...
>
> Sorry for the long post - but I hope I was able to wet your appetite towards modular Smalltalk.
>
> Bye
> T.
>
> [1] https://docs.sonatype.org/download/attachments/1999021/pom-dependency-graph.png?version=1&modificationDate=1212678465631
>

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

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

> Torsten Bergmann wrote:
> > Andreas Raab wrote:
> >> BTW, for people who'd like to install HelpSystem with Installer instead
> >> of Metacello, use this:
> >
> > NOOOO!!!!!
>
> Heh :-) I think I'm starting to understand our differences (actually
> more from your private mail than from this one) and I think it comes to
> what Metacello is *today* vs. what Metacello *may be* in the future.
>

> First of all, I completely understand what a package management system
> is, what it does, why it's a good idea. You'll hear no arguments about
> that other than my opinion that we do indeed need a package management
> system. Urgently.
>
> 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
> b) The ability to install packages
> c) The ability to reflect about package
> d) The ability to uninstall packages

>
> 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. In other words, the package spec is transient, the real input to
> Metacello is *code* (a ConfigurationOfXXX) which makes it all but
> declarative. 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). All of this completely
> violates the idea of why one uses declarative specs, namely to have
> *fewer* dependencies that one needs to deal with in order to
> "understand" the spec.

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

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

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

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

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

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

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