I know I made the original suggestion about renaming the configs and Seans point is a vlid one, but I am not sure about renaming being a "solution" to the basic problem ...

One of the ideas in Metacello is that a project can refer to another project by name (i.e., ConfigurationOfXXX). For example GemTools requires FFI so I have a requirement for ConfigurationOfFFI - the cross-platform config)... In a configuration package the configuration for FFI might be named something like InstallerForFFI so when GemTools is loaded ConfigurationOfFFI will be used instead of InstallerForFFI, which I assume is not what is desired....

I'm not trying to discourage the exploration of the configuration package space, but this is an issue that would be difficult to resolve...I think.

In the last week or so I've been thinking along the lines of "white lists" for configurations and the idea that a SqueakMap "white list" for configurations could work.

A white list for configuration would consist of:

  - Configuration: name, mcz version, UUID of package
  - repository
  - version
  - load list (list of names of groups/packages to be loaded)

It seems to me that a variant of SqueakMap could record the above information satisfying the "community participation" aspect while allowing for configurations to be introduced from the wild ...

When loaded from SqueakMap, it _is_ possible to identify the list of configurations that would be loaded (prior to the Metacello load) so one could arrange to ensure the the SqueakMap configurations were used for all projects (by preloading the Config using the SqueakMap info instead of the information normally embedded in a config)...

In this way if one uses SqueakMap to do the load, one will be ensured that the SqueakMap specs are used ... on the other hand it would be straightforward to customize ones image and deviate from what's in SqueakMap if one wanted to...

All of this would be possible without needing to maintin copies of information from configurations ... and specifing an mcz version/repository combo would pretty much provide stability...

This should be enough for folks to chew on (and spit out if it doesn't taste good:)...

Dale
________________________________________
From: squeak-dev-bounces at lists.squeakfoundation.org [squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Andreas Raab [andreas.raab at gmx.de]
Sent: Friday, May 21, 2010 11:19 PM
To: The general-purpose Squeak developers list
Subject: [squeak-dev] Re: Cross-fork Metacello configurations

On 5/21/2010 9:14 AM, Sean P. DeNigris wrote:
> What would be the best/easiest way to deal with this?
>
> If the configs have to be forked, then Metacello really loses value (i.e.
> #squeak and #pharo).  And, I do a lot of work in both forks, so it would be
> a shame to pick one to upload to and not share work that has already been
> done with half the users.

How about you try using a proxy configuration for that? We've talked
about this earlier: If you want to keep a single configuration
externally, make a proxy config that simply loads the external config.
It would be good to have an example for that.

Cheers,
   - Andreas