[Seaside-dev] Detecting installed Seaside versions?

Wed Nov 25 23:39:46 UTC 2009

Colin,

Very interesting work and if Metacello becomes extinct I would be a happier man ... 

When I read your mail, I was struck by the thought that perhaps your idea of the end user and my idea of the end user are different. And maybe I haven't been clear about who the Metacello end user is...

The Metacello end user is another _developer_ who is trying to put together a system made up of a number of projects some of whom have dependencies upon one another and some of whom do not. 

The Metacello configurations provide version and dependency information to the developer to use for development purposes. It _is_ a glorified load script, but it is structured such that it does not need to be a _monolithic_ load script. It also happens to be a multi-platform load script. It also happens to be versioned, which is how this topic got started.

The poster child developer for Metacello is someone who is building a collection of Seaside3.0 components that he expects other people to use in their own development projects. The poster child must ensure that when someone decides to use his component that they are able to get the right stuff loaded from the other projects that his component may depend upon (does it use AJAX, does it need email, does it do XML processing, does it need smacc...what parts of the Seaside3.0 package archipeligo does it really need)...The end user of the poster childs project needs to be able to independently integrate bugfixes from the packages that the poster childs component depends upon, so the end user needs dependency information as well...A single metacello configuration published by the poster child can provide all of the above information so the end user is not burdened by 'figuring out' what he needs to make it work nor does the end user have to wonder which version of Seaside3.0 9et.al) the component was originally written against, since that information is encoded in the configuration as well ... <deep breath>....:)

My understanding (which is probably flawed) of SAR files is that they are monolithic entities ... there is no internal dependency information other than things are loaded in a fixed order.. there are no conditional loading options... there is no SAR to SAR external dependency information ...there is no way to load a partial graph from a SAR...These are the issues that Metacello is attempting to resolve.

With that said SAR files sound like wonderful things for delivering a finished product to someone and from that perspective Metacello is uninteresting.

In the end I think that Metacello and SAR are tools aimed at different problems.

Dale

----- "Colin Putney" <cputney at wiresong.ca> wrote:

| On 25-Nov-09, at 9:45 AM, Dale Henrichs wrote:
| 
| > Colin,
| >
| > The down-side to having a constant in the image that records the  
| > "last version loaded" is that users are free to load packages  
| > independently, without ensuring that the "last version loaded" is  
| > updated appropriately.
| >
| > It is certainly a good enough solution.
| >
| > The point of Metacello is to create a specification for a particular
|  
| > version, so that no matter how that particular version got loaded  
| > the current image can be compared to the spec and the "current  
| > version" can be calculated.
| >
| > It's one of the fundamental problems with "Package management" -  
| > when the package data base does not match the installed system.  
| > Metacello is not immune to the problem, but since it dynamically  
| > calculates the version based on a spec and the existing image, it  
| > has a chance of getting a good answer.
| >
| > Ad hoc solutions start breaking down when a particular user is  
| > interested in reasoning about cross project dependencies, based on 
| 
| > versions ... a problem that every current Smalltalk programmer
| has:)
| >
| > I'm not going to say that Metacello is the last word in package  
| > management for Smalltalk, but it _is_ an attempt to address some of 
| 
| > the larger problems that the consumers of multiple software projects
|  
| > have to deal with...
| 
| I think one of the biggest problems Squeak (and Gemstone, to the  
| extent that it participates in the Squeak ecosystem) has today is that
|  
| there aren't any good mechanisms for distributing code for deployment.
|  
| Monticello makes a reasonably good versioning tool for development,  
| but it was not designed for *distributing* software. It does have the 
| 
| nifty property that a package version is contained in a single file, 
| 
| and so we've been using Monticello's internal repository format as a 
| 
| distribution format. Just download an mcz file and load it into your 
| 
| image!
| 
| That wasn't great, but it worked OK in the early days of Monticello  
| when most projects were single, monolithic packages. These days,  
| though, we've got large, multi-platform projects being developed with 
| 
| Monticello, and configuration management at the level of packages gets
|  
| really difficult. OmniBrowser has over a dozen, Monticello 2.0 has  
| over two dozen, and Seaside has about 5 dozen! So we've had a little 
| 
| cottage industry of scripts to pull down all those packages and get  
| them installed.
| 
| This is bad for many reasons, but I think the worst effect is to  
| introduce coupling between the users' installation process and the  
| developers' development process. All these scripts rely on knowing how
|  
| the source code of the project is organized, where it's stored, and  
| perhaps even the social dynamics of the development team. If I decide 
| 
| to start using Monticello 2 to develop OmniBrowser, or even move my  
| repository to another host, it's going to break all those installation
|  
| scripts that people have put together.
| 
| I'd like to find a better way to distribute Squeak applications, and 
| 
| for my own projects I'm trying to break that coupling between  
| installation and development. For example, I've started releasing OB, 
| 
| MC2 and Filesystem using SAR archives rather than mcz files. This  
| removes the need for users to have Monticello installed, and if my  
| FSReleaseInfo experiment pans out, will make it possible to upgrade to
|  
| future SAR-based releases easily, again without using Monticello.
| 
| Now, it's true, this scheme only works if you install and upgrade  
| using my SAR releases, but I don't think that's an unreasonable  
| requirement. If all you want to do is *use* my application, as opposed
|  
| to hacking on it, you don't need to install things manually anyway.  
| Folks who want to participate in development, on the other hand, will 
| 
| need to know where the repositories are, what the packages are and  
| their relationships etc, but that's to be expected.
| 
| The problem I have with Metacello is that it's really just a cleaner, 
| 
| more managable version of the install scripts I'm trying to get rid  
| of. On top of that, it introduces a new dependency for installation - 
| 
| now users have to have Metacello installed as well as Monticello.  
| Where I find Metacello valuable is as a development tool, for managing
|  
| the metadata I need to reliably build development images and SAR  
| archives. Unfortunately Metacello wasn't designed for that role, and 
| 
| I'm not terribly comfortable twisting it to my purposes, because  
| that's what got us in this mess in the first place. :-)
| 
| Colin
| 
| 
| _______________________________________________
| seaside-dev mailing list
| seaside-dev at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev