I reflected a bit more on your requirements. How about the following?
Put a separate reference for the project in each platform-specific section. I
combine this with a #file: declaration because otherwise your package cache
will play dirty tricks on you if it has a newer version of the ConfigurationOfB
in it. This is really important.
spec for: #common do:[
spec project: 'B' "empty def to allow dependency reference inside the
#common secion"
]
spec for: #pharo2.x do:[
spec
project: 'B'
with: [
spec
className:'ConfigurationOfB';
versionString: #stable;
file: 'ConfigurationOfB-johndoe.1.mcz';
repository: '<meta repo for pharo 2.0>'
]
]
spec for: #pharo3.x do:[
spec
project: 'B'
with: [
spec
className:'ConfigurationOfB';
versionString: #stable;
file: 'ConfigurationOfB-johndoe.2.mcz';
repository: '<meta repo for pharo 3.0>'
]
]
On 22 Mar 2014, at 23:06, Pharo4Stef <pharo4s...@free.fr> wrote:
> We were discussing about that.
> My point is that the system should work if the catalog fall apart.
> Now others told me that in other community this is the inverse. People only
> refer to the catalog.
>
> Since we did not get last year and this year the engineer I requested to work
> on the validation of distirbution we did not make progress
> on that front because we are busy.
>
> For me I do not use SqueakSource not because it is written Squeak but because
> I think that squeaksource is over and too old.
>
> Stef
>
>> I'm currently browsing the various ConfigurationOf in MetaRepoForPharo30
>> catalog hoping to find a pattern to serve as guidelines, but what I see is a
>> messy variety of solutions:
>>
>> - direct reference to specific source repositories of package B as Johan
>> suggested (and the successive baselines are effectively tracking motions of
>> B)
>> IMO the worst thing, I don't manage B and don't want to update my
>> ConfigurationOfA each time B moves.
>>
>> - references to ConfigurationOfB thru squeaksource MetacelloRepository.
>> My preferred solution. I don't care if the catalog is centralized on
>> squeaksource, Smalltalkhub or whatever, but I want a centralized catalog
>
> Me too.
> Now the question is the following one.
> Ideally I would like to have one inbox and that configuration move to the
> catalog for their version.
> (Because I do not see the point of having around old versions of projects
> that do not load in the given version).
> I explained that in the Pharo vision document.
> Now may be other solutions are better.
>
> Stef
>
>
>>
>> - refrences thru MetaRepo catalog du jour (tracking motions of MetaRepo
>> across baselines)
>> My original question, using secondary catalogs is not a problem if they are
>> just a duplicata, but I prefer to ask, because it sounds strange to have
>> multiple catalogs just to implement a filter (the filter being select those
>> packages that are tested and approved in pharo x.y)... Certainly a
>> workaround for a missing feature of Metacello.
>>
>> - a mixture of the 3 solutions above for some packages!
>> That appears as randomness from my POV, or like of guidance
>>
>> So again, what are the best practices currently, and could we think of it in
>> a bit longer term?
>>
>>
>> 2014-03-22 21:51 GMT+01:00 Nicolas Cellier
>> <nicolas.cellier.aka.n...@gmail.com>:
>>
>> 2014-03-22 21:27 GMT+01:00 Johan Brichau <jo...@inceptive.be>:
>>
>> I don't understand what squeaksource has to do with that.
>> With main repository, I mean the repository of the project itself.
>>
>> Almost all ConfigurationOfXXX are hosted together with the project itself.
>> They are also referenced in that repo. The MetacelloRepo or MetaRepos are
>> almost always secondary copies (if not, they should be)
>>
>> Johan
>>
>>
>> Arghh NOOOO, so that is really going to be a problem for me !
>> With MetacelloRepository I absolutely don't care where to find a specific
>> package, I have some kind of centralized catalog.
>>
>> Now, if I must track each and every motion of package B from squeaksource to
>> ss3 to SmalltalkHub to github to (what's next ?), the idea of catalog is
>> completely broken then...
>>
>> Nicolas
>>
>>
>> On 22 Mar 2014, at 21:10, Nicolas Cellier
>> <nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>>> OK, if the MetacelloRepository on squeaksource can still serve as
>>> reference, I'm perfectly OK with it, I don't know why I had this impression
>>> that anything beginning with those 6 letters was going to be seen as a
>>> problem ;)
>>>
>>>
>>> 2014-03-22 18:53 GMT+01:00 Johan Brichau <jo...@inceptive.be>:
>>> Why can you not reference the main repository? The meta repository is just
>>> a place where the configuration loader tool fetches them.
>>>
>>> Platform-specific elements go in the separate 'sections' of a baseline or
>>> version method.
>>>
>>> Don't make separate branches of the same ConfigurationOf class. You will
>>> not only make your life hard but also confuse all users!
>>>
>>> Maybe you can explain why you think you need those?
>>>
>>> Johan
>>>
>>> On 22 Mar 2014, at 18:20, Nicolas Cellier
>>> <nicolas.cellier.aka.n...@gmail.com> wrote:
>>>
>>>> I have some packages A that depend on another package B.
>>>> In Metacello, I can easily declare the dependency
>>>> spec
>>>> className: 'ConfigurationOfB';
>>>> versionString: #'stable';
>>>> repository: '
>>>> http://www.squeaksource.com/MetacelloRepository' ].
>>>> But the repository is hardcoded here.
>>>>
>>>> My problem is that I'd like to edit a ConfigurationOfA valid for pharo
>>>> 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20
>>>> and another copy in MetaRepoForPharo30.
>>>>
>>>> Since the repository is hardcoded, this is going to be a problem because
>>>> the MetaRepo will then cross-ref other repositories and weaken robustness
>>>> or miss uptodate ConfigurationOfB...
>>>>
>>>> I'd like to avoid maintaining many branches of ConfigurationOfA.
>>>>
>>>> How do others resolve this?
>>>
>>
>>
>
