Some observations from the perspective of as a newbie on Pharo Package Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage.... 1. When I read about Metacello being the package management system, I expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time. (*) While technically a "command" is like a verb, and Gopher is like a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same. 2. The strong convention of naming things ConfigurationOfXXXX is somewhat redundant from a user perspective. 3. If copy-paste into the Workspace from a web site a sample package load (for example b> below) and then highlight the whole thing and execute, it tells me "Unknown variable: ConfigurationOfSqueakDBX, please correct, or cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere.... The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds further complexity in the eyes of a newbie. Based on the above points, it would be nice to have... a> Metacello configuration: 'SqueakDBX' load rather than... b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load. While only a small saving in typing, I think it significant for newbies in terms of polish and the marketing message that Metacello really is the chosen package management system. A very rough implementation (with much of the syntax likely wrong) might be just... c> Metacello class >> package: aPackage c> | packageConfig | c> packageConfig := 'ConfigurationOf', aPackage; c> Gopher new c> squeaksource: 'MetacelloRepository'; c> package: packageConfig c> load c> ^((Smalltalk at: (packageConfig asSymbol)) Now after I've written the above I contemplate that there must have been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions c. A GUI for browsing compatibility tables from a continuous integration system that tries different permutations of Montecello packages together. 4. It seems that every ConfigurationOfXXX has its own category in the SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar. 5. The sample Metacello PBE is very good in the detail for developers to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. Cheers, Ben