El jue, 05-08-2010 a las 19:45 +0200, Norbert Hartl escribió: First some terms that I use:
- Software Package: a collection of classes that conform a working, useful software. Often is convey to other users in the form of one o various monticello packages. - Software Release: a stamped snapshot of a Software package - Monticello: a software that creates mcz files, called monticello packages that comprises a set of classes that are part of a Software Package. - Configuration, ConfigurationOfXXX: Metacello configuration that loads a set of Monticello Packages that together form a release of a Software Package. > > > > > I think Javier is right. I, too, have problems to understand how this > should work. A lot of the ConfigurationOfxxx files are about software > projects that run on pharo and aren't _part_ of it. Just take a > project like seaside. That is a project that runs on a lot of > platforms (hence the existence of grease). The ConfigurationOfXXX packages _are_ for packages not part of a core or released image. That is their raison d'être. > > > Clarity. As is very likely that different releases of a package will > > have distinct requirements in: > > - dependencies > > > > > that is what metacello is all about Yes, but it complicates a lot when you try to use a single Configuration to load several releases of a Software Package in several releases of Pharo. Just see the size of the configuration of ConfigurationOfSeaside28 that handles pharo, sqeuak and gemstone installs. I'm sure that Dale tried to add also support for Seaside 3.0 in the same Configuration but that were so much effort compared to just create a new ConfigurationOfSeaside30 that handles only the required mcz packages for 3.0 and forgets and don't care about the mcz packages for 2.8. I was about of doing the same for ConfigurationOfMagma. I considered create a new ConfigurationForMagma11r2 that handles only the packages for that release (that are not so distinct to the previous release as in the case of Seaside, but the scenario is the same). No way. That is not the solution. Not at a long term. So the metacello repositories idea (that was already discussed before) was a perfect solution. > > > > - preinstall/postinstall actions > > - registering with system services (menu, mail systems, sockets, > > startup/stop list) > > > > > that is platform specific. For seaside that needs to be solved from > the seaside crew otherwise they won't stay cross-platform very long. > And I think there is no point in many people writing in a > ConfigurationOfSeaside30 file. Those files should be very dependent on > the people writing seaside. Do you think you will add pharo1.1 stuff > to the file? The ConfigurationOfSeasideXX aren't created, maintained, debuged or cared by the Seaside core developers. And that is good. They concentrate in the Seaside code, and the Configuration maintainers (Dale) concentrate in the installation issue in the various platforms. Of course the maintainer coordinate with the upstream developers to solve platform specific problems, and of course nothing stops a core developer of a Software Package to maintain the ConfigurationOfTheirOwnPackage (as OSProcess' creator is doing) > > > - number of monticello packages composing the package you're > > installing > > > > > that's dependencies Yes but they are distinct for each Pharo release: - because maybe the Pharo release already includes some package previously required by the package (e.g Announcements being part of the core) - because the new Pharo release unloaded some package that previously was part of the core system (e.g. if it depends on Crypto and crypto isn't anymore part of the core image). And also they are distinct in each Software Package release: - because the Software Package was simplified to not use some package anymore - because the Software Package includes new functionality that isn't part of the core system > > > - use of system infraestructure (announcements, transcript, menus, > > help > > system) > > > > again platform handling ditto. > > > > > it will be a nightmare to have code to cope with all those > > conditions in > > a single monolithic giant metacello package, even if metacello is > > capable of do it. > > What if after 4 years of development the package has had 15 > > releases, > > that will means that you'll have possibly 15 > > baselines/predoits/postdoits all listing in the method pane of the > > browser. To someone trying to understand the configuration, it will > > be a > > lot of junk to discard before he understand only the bits that > > matter > > for the release he is interested in. > > > > So, it is healthy to have a distinct configuration in each release > > (even > > if in the current release started as a copy of the previous release > > configuration), to crop the things the _maintainer_ thinks are not > > needed anymore or simply that he doesn't want to maintain anymore. > > All > > the software has a lifetime and distinct repositories gives us the > > possibility to determine the time to end support for a given release > > > > > > > Please correct me if I'm wrong. By copying the configuration files you > make a snapshot of the project without the possibility to alter > anything. The configuration file itself is modified by the software > project the file is for. Probably the software project does not want > anyone to write in the config file. I don't understand this previous paragraph. What config files are you refering to, the Metacello configuration? If so they are in Read/Write repositories to all to modify. Also, they are by the license notice in the page, MIT, so there is no way someone can stop other to modify the Configuration for adapting it when a new Pharo release (or gemstone or squeak) is out. > > > To me a central repository is essential. It is a single well-known > source and it carries the idea of cross-platformness :) Isn't that > would you are trying to solve not just another ConfigurationOfXXX > file. For the moment let's call it ConfigurationOfPharo10Universe. > There you can refer to every single version in another > ConfigurationOfXXX file that is said to be runnable in that platform. > And you can decorate it with pre-/postDoits as you want. Yes, I know, the ConfigurationOfMagma does depends on other packages too: OSProcess, WriteBarrier. That is not a problem. The problem is the proliferation of pre/post doits and custom conditionals to handle the distinct combinatios of Pharo (or gemstone or squeak) releases and Software Package Releases > > I think that most of this software management tasks are solvable by a > description of "requires" and "provides". And metacello solves it > well. As an example let's think of an example like > ConfigurationOfPharoWebDeveloperImage (maintained by the image > provider). The developer image develops linearly hence no version > number in the file. The ConfigurationOfPharoWebDeveloperImage has > dependencies to 20 other software projects that are all defined in a > ConfigurationOfPharo11Universe (maintained by the community). Let's > say it has a dependency on 'Seaside 3.0'. > ConfigurationOfPharo11Universe offers 'Seaside 3.0' and has a > dependency of 'Seaside 3.0.3' in ConfigurationOfSeaside30 (maintained > by the seaside maintainers). ConfigurationOfSeaside30 has a dependency > to 'Grease 1.0.3' in ConfigurationOfGrease. So let's asssume finally > that ConfigurationOfGrease would have a dependency to 'Pharo 1.1' when > run under pharo1.1 or to 'Pharo 1.1 compat package' when run under > pharo 1.0 (metacello allows us to do that). And that is precisely the point. As time goes on, the number of this "conditional" will grow exponentially, lowering the quality of the Configuration and difficulting the maintenance of it. If all of this can be solved by simply copying the current configuration to a new repository on squeaksource when a new Pharo release is out, then better for all, mainly for the maintainer that is the one doing the hard work of maintaing the configuration. > All of these descriptions require and provide anything. And the > descriptions are services offered from one group to another taking a > certain responsibility. You can always rely on things like "Seaside > 3.0" if you trust the people and if not than you use "Seaside > 3.0.4rc2a". > > > What I wanted to say is that there are plenty of situations where you > want to cluster software packages together. By copying the files you > just double to stuff without being able to tweak. I don't understand this part too, why woulnd you be able to tweak it? Also, if the ConfigurationOfMagma, for example, is copied to MetaRepoForPharo1.3 (when Pharo 1.3 is out) and it needs ConfigurationOfOSProcess then I copy also ConfigurationOfOSProcess from MetaRepoForPharo1.2 to MetaRepoForPharo1.3 and then all is working correctly again. > Removing the packages from the MetacelloRepository as Stephane > suggested would just make them platform dependent. Having less files > and clear roles who might change them is something achievable IMHO. > Tearing things apart (by copying) lowers sometimes integration effort. > Or to say with view from the XML world: "If you want to > integrate/cooperate than XML schema is for you If you don't want to do > that than use XML namespaces". I don't get it. :) A final point, the idea is that the end users won't see how things are implemented. The tools will have to be modified to understand this MetacelloRepositories thing. Gofer, GoferProjectLoader and Metacello itself will need to add an indirection when accessing repositories so that they access the correct repository for the image they are running on. With this the user will do Gofer new universe; "Here Gofer points to the Pharo10, Pharo11, etc" package: 'ConfigurationOfMagma'; load; Or better yet: Gofer project load: 'Magma'. "using GoferProjectLoader modified to understand MetacelloRepositories" and when doing a: ConfigurationOfXXX project latestVersion the references to required ConfigurationOfXXX dependencies will need to be taken from the same repository where the ConfigurationOfXXX was got. This way the "Universe" analogy of self-contained group of packages known to work in a given release is fulfilled. Cheers -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
