Re: [Pharo-project] a process to maintain non core package
Mike, I have been working on Metacello which is a package management system for Smalltalk. Metacello is built on top of Monticello and should also be able to manage MC2 artifacts. Metacello runs on Squeak, Pharo and GemStone. It is currently in alpha as I am still working on making it "feature complete". Information for downloading it can be found on the Monticello mailing list - there is a tutorial (see the version 0.6 announcement). I created Metacello to address specific needs that I have run into while maintaining GLASS: - Named versions associated with lists of explicit Monticello file names. One can declare that version 0.3 consists of: 'Example-Core-anon.9' 'Example-Tests-anon.3' 'Example-AddOn-anon.1' 'Example-UI-anon.1' When one comes across an announcement of version 0.3 for the Example project you will know exactly which versions of the packages need to be loaded. Furthermore, you can evaluate an expression like the following to load version 0.3: (ExampleProject version: '0.3') load - Package to package dependencies. One can declare required packages like the following: 'Example-Core-anon.9' 'Example-Tests-anon.3' requires: 'Example-Core' 'Example-AddOn-anon.1' requires: 'Example-Tests' 'Example-UI-anon.1' requires: { 'OB'. 'Example-AddOn'. } From the above statements, the package load order is derived and used when you load the project: (ExampleProject version: '0.3') load It is also used to determine _which_ packages should be loaded when an expression like the following is executed: (ExampleProject version: '0.3') load: 'Example-AddOn' This statement causes 'Example-Core-anon.9', 'Example-Tests-anon.3', 'Example-AddOn-anon.1' to be loaded in order. - Package to Project dependencies. In the above example 'OB' is a named reference to the OmniBrowser project and if 'Example-UI' is loaded, then the OmniBrowser project will be loaded. - Conditional package declarations. One can declare package versions that will be conditionally loaded for Squeak, Pharo. or GemStone. For GemStone I also declare different package versions based on which version of GemStone is being run. There is more, including a spartan OB interface... Currently I am integrating Metacello into the GemStone/GLASS build process. Soon I will be using Metacello for managing updates for GLASS users - the version of GemTools running on the 1.0beta is managed with Metacello... In parallel I am working on making Metacello feature complete for the 1.0 release (only a couple features left on my list). The biggest item remaining is a tutorial covering the all of the features (or a least the most important). Metacello is under the MIT license. I think that Metacello addresses at least a couple of requirements for Pharo, but then I'm biased:) Dale ----- "Michael Roberts" <mike@mjr104.co.uk> wrote: | do we have a list of candidate package management systems? | | cheers, |
El dom, 09-08-2009 a las 10:29 -0700, Dale Henrichs escribió:
- Package to package dependencies. One can declare required packages like the following: 'Example-Core-anon.9' 'Example-Tests-anon.3' requires: 'Example-Core' 'Example-AddOn-anon.1' requires: 'Example-Tests' 'Example-UI-anon.1' requires: { 'OB'. 'Example-AddOn'. } From the above statements, the package load order is derived and used when you load the project: (ExampleProject version: '0.3') load It is also used to determine _which_ packages should be loaded when an expression like the following is executed: (ExampleProject version: '0.3') load: 'Example-AddOn' This statement causes 'Example-Core-anon.9', 'Example-Tests-anon.3', 'Example-AddOn-anon.1' to be loaded in order.
This is very good, one thing that the package management system of Debian has is that you can indicate a minimal version for a required package: for example, following your code snippet: 'Example-Core-anon.9' 'Example-Tests-anon.3' requires: 'Example-Core' minVersion: 9 'Example-AddOn-anon.1' requires: 'Example-Tests' minVersion: 1 maxVersion: 3 'Example-UI-anon.1' requires: { 'OB' . 'Example-AddOn'. } This way, the package system doesn't have to install a exact version if a group of versions of the package required can equally work. This permits to have a package, say 5 of a package that have a new feature that I need in my image and not be overwrote by a dependency of other package that needs exactly version 3 that doesn't have the feature that I need. Maybe Metacello has this functionality, but if not, it would be, I think, easy to add it, just a comparation that the version available in the system meets the criteria stated by the package dependency. Also, a form to force the install a package even if not all the dependencies are met is good, in particular to test some experimental package. For more information you can refer to the dpkg/deb/aptitude tools in the debian system. Of course that tools do a lot more but we don't need, at least for now, all the features. http://en.wikipedia.org/wiki/Aptitude_(program) http://en.wikipedia.org/wiki/Deb_(file_format) http://en.wikipedia.org/wiki/Dpkg All of them are GPL but I think that a new implementation, without use the code, and in another language, using only the ideas, is permited and can be integrated in Pharo as MIT code.
participants (2)
-
Dale Henrichs -
Miguel Enrique Cobá Martinez