I posted this on Squeak-dev @ http://forum.world.st/Community-Supported-Packages-td2217473.html#a2218970: I eagerly read all the discussions and offer my humble contribution (posting to Pharo too, because I think the benefit is cross-platform): I'm overjoyed that we are digging in and making packages easily loadable (or clear that they are not). I don't know what I'll do with all the hours I currently spend fishing for working versions ;-) Overall the goals seem to be (put best in a post from Mariano Peck): * have a specific catalog of working and tested projects for each platform (Pharo 1.0, Pharo 1.1, Squeak 4.0, Squeak 4.1...) * Be able to have a hudson server running and testing such configurations. * Unified way to load a project. * (I added this one) have the least amount of effort for the developer The Pharo and Squeak versions both sound intriguing. I suggest one addition that would magnify all of the above, and eliminate the accidental complexity that versioning is adding to the mix: ***Extend Metacello specs to account for platform version (e.g. Pharo 1.0 vs. 1.1)*** In effect, since we are distilling the platforms down to the pure good stuff - each version is a whole different platform; from a developer's perspective, it's the same process porting to different forks and porting to new versions of the same fork - either way, incompatible interfaces. A hypothetical developer perspective: - Porting from Squeak to Pharo: I'm a developer with a project that works on Squeak 4.0. Now, I decide to port it to Pharo 1.0. So I crank up a new image and... wait, how do I load it? I don't have a ConfigOf. So I either alter the Config #squeak to #squeakCommon, or load manually. Now, it doesn't load because there are classes that don't exist in Pharo, so one by one, I move the platform-specific code into Platform.squeak and Platform.pharo. - Pharo 1.0 to Pharo 1.1: Now, Pharo 1.1 is released, with even fewer classes - tight core, yay! So I go through the same process, but now I have *three platforms* - Pharo 1.0, 1.1, and Squeak 4.0. User perspective: simple - I want to have *one* place to go where I know that all the packages there will work in my image, and cut out all the junk. And, if I'm feeling adventurous, I'd like *one* place to see what else is out there, but very clear that it's not up to community standards - for inspiration, to port to my platform, or to steal code :) Once you have Metacello handling the versions * the developers go from fork*version configs to one config * the version problem is handled * all other features of the current plans are preserved This is what I envision at the intersection of what's been proposed and Metacello versioning: * Configs are either: - in one central location; it won't matter because we went from projects*forks*versions Configs to just 1*projects. - or, kept with the projects they reference e.g. pick squeaksource.com, and every project repository keeps its own ConfigurationOf (might diminish the community involvement if read-only repos) >Andreas (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473): >Good things about it are that >it's community maintained. Everyone can update everyone else's >contributions and although that's not generally done, it offers a >community approach to making sure things work. * Each platform (fork + version combo) (via hudson server? I don't know much about them) tries to load each Config from the central repository. If it meets the community standards (no conflicts, tests, etc.), either the Config is copied to that platform/fork's list of compatible Configs, or a reference is added. * If it doesn't load, another list could be kept with the result of the attempt to load, so anyone who wants to use or port it has a heads up on the status. So: * we don't need a separate Config for fork*version platforms. Right now, it seems the implementation and behavior are collapsed - we don't care where the actual Configs are (at least in the Pharo plan), as long as we know which ones work. Which resolves Andreas's concern with a single repository: > Andreas (http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473): > Also, I don't think that a single repository is a feasible option in the long > term - it seems to me that supporting the cross-product of image and > package versions is going to be problematic before too long. And of > course browsing repositories with several dozen of packages to find what > you need isn't exactly fun either. and eliminated manual fiddling with the Config file: > Pharo proposal @ http://groups.google.com/group/metacello/browse_thread/thread/42c088d58acfb3... > [developers will copy configs that work in Pharo x.y to] PharoxyMetacelloRepository, then add class>>load for Pharo 1.0 version. * there is still one place to install for a user's platform * you really do get "a standard way to load the packages on such repository: just send the message load" because the spec already knows whether it will work on that platform * you still get a Pharo [and Squeak] release with the correct repository as default (already added in Monticello Browser) - this is your list you copied over Thanks. Sean -- View this message in context: http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-please... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.