Esteban, I think that what you are proposing makes a lot of sense, although I am a bit biased ... a central repository would definitely make it very simple to find projects that are managed...
It seems that in addition to to the Monticello repository of configurations, a catalog website that provided a searchable index on the projects and the project meta data (project description ... release status ... project dependencies ...). Having a central repository is a good first step... I have a cross-platform bias. Many of the Pharo projects can be ported to GemStone (and Squeak) using a common Metacello configuration, so I think the central repository would end up serving cross-platform users. FYI, yesterday I created a google group for Metacello discussions (http://groups.google.com/group/metacello/members). As a Metacello user, you will want to join. Dale ----- "Esteban Lorenzano" <[email protected]> wrote: | Hi all, | I’m begining to transfer all my projects to metacello (I think this is | the best package manager present today for pharo), and I have an idea | I | want to share and discuss: | | I think we need a metacello based centered repository. | | The universe doesn’t fit with metacello and squeakmap even less. | | So this is my idea (it is based on “ibiblio” for maven/java and | apt-get | for ubuuntu): | -we can create a project on squeaksource called | “PharoMetacelloRepository”, where people can put its public metacello | configuration packages (for example ConfigurationOfSeaside30, | ConfigurationOfDeimos, etc.). | -we should integrate metacello to pharo core (like Gofer now) | -we’ll need to create a new class “Loader” | | What “Loader” does? it loads versions from “metacello repositories”, | for example: | | Loader default latest: ‘Seaside30’. “This will load latest version of | ConfigurationOfSeaside30’ | | Loader class>>#default answers a loader pointing to | “PharoMetacelloRepository”, but you could define others (for your | private projects). | | How Loader works? | 1) validate loading a valid metacello configuration package (we’ll | need | to define this later | 2) load metacello package | 3) do something like “MetacelloConfigurationClass project | loadLatestVersion” (for #latest), and the corresponding sends for | specific versions, etc. | | I think this will solve any package management problem, by using | something already present (SqueakSource), and of course, we could | think | on better repository places/formats later (but we will be “on the | road”) | | So, what do you think? | | btw: If the community agree, I’m offering my self to implement this | idea ;) | | Cheers, | Esteban | | | | _______________________________________________ | Pharo-project mailing list | [email protected] | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
