Location of Metacello package dependency
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?
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.nice@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?
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 <johan@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.nice@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?
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
On 22 Mar 2014, at 21:10, Nicolas Cellier <nicolas.cellier.aka.nice@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 <johan@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.nice@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?
2014-03-22 21:27 GMT+01:00 Johan Brichau <johan@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.nice@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 <johan@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.nice@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?
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 - 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.nice@gmail.com>:
2014-03-22 21:27 GMT+01:00 Johan Brichau <johan@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.nice@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 <johan@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.nice@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?
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.nice@gmail.com>:
2014-03-22 21:27 GMT+01:00 Johan Brichau <johan@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.nice@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 <johan@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.nice@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?
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 <pharo4Stef@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.nice@gmail.com>:
2014-03-22 21:27 GMT+01:00 Johan Brichau <johan@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.nice@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 <johan@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.nice@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?
2014-03-23 8:14 GMT+01:00 Johan Brichau <johan@inceptive.be>:
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>' ] ]
Thanks Johan, that makes sense. I understand that specifying a specific version of ConfigurationOfB is defensive, and in theory, yes that's the configuration I tested. Anything newer may fail - letting case of broken configuration apart, the #stable version could go thru a major revision and the API become uncompatible... What I'd like better would be semantic versionning style major.minor.revision rather than symbolic #stable. This way, when I would specify version 3.2+.x of project B, that would mean major=3, minor>=2, any revision. But right now, can we really trust such semantic numbering policy? The other thing I'd like is to somehow specify: - pick the configuration in official catalog for this dialect It makes perfect sense to somehow factor it out. Otherwise, imagine that this information will be repeated in a hundred packages or so... Thus a specific pharo.y.x requirement would be exceptionnal, if ever a configuration was not yet officially ready in the catalog. Last thing, I don't really want to protect myself from a broken ConfigurationOfB in the catalog for at least 2 reasons: 1) If I freeze a ConfigurationOfB version, then I can't profit by newer bug fixes, or worse, I'm subject to configuration rot due to package motion (like it was erased from squeaksource then ss3 then ...) 2) A transfer to official catalog implies that the ConfigurationOfB is at least maintained and cared upon and will be fixed within a few days. In between I can rely on copying older images rather than re-installing, but that's just me. As for the package-cache, I didn't face the problem so far because Pharo one click comes with its own package-cache and I renew the install rather often (note that often but the interval of time between two glimpses of Pharo is long enough such that the update stream rarely works for me). But it sounds to me like a package-cache problem, and if it is, we should better correct it than patching like mad our already complex enough Configuration as a workaround. On 22 Mar 2014, at 23:06, Pharo4Stef <pharo4Stef@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.nice@gmail.com>:
2014-03-22 21:27 GMT+01:00 Johan Brichau <johan@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.nice@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 <johan@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.nice@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?
On 22 Mar 2014, at 23:06, Pharo4Stef <pharo4Stef@free.fr> wrote:
Now others told me that in other community this is the inverse. People only refer to the catalog.
Yes, that is perfect if there is one catalog for the community. Not a different catalog per version of the platform (pharo2.x, pharo3.x,...). A metacello configuration itself has sufficient methods to specify correctly how to load on which platform. If you make a single meta repository, you can check if the configuration has a #stable version for the platform and show that in the configuration browser. Now, I *know* that people make mistakes and that they can screw up a configuration in the future and that you want to protect yourself from that by making different catalogs such that they are frozen. But I really think this actually makes matters more complicated (i.e. the reason for this thread). To make a snapshot (e.g. for Pharo3.0), you can reference the specific version of a configuration (using the #file: message) to protect yourself from someone messing up in a future version of the configuration. This is what I do to protect my own projects from suddenly being broken because some changed a configuration in a way that breaks it or just messes up my load procedure. It works well.
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).
The configuration browser can require a configuration to explicitly specify a #stable version for the platform, otherwise it does not show it as 'supported' ?
I explained that in the Pharo vision document. Now may be other solutions are better.
Version management is difficult... I guess we all have a love-hate relationship with Metacello ;-) For me, Metacello is doing a good job but the problem is that it's almost always very difficult to find out why it does something you do not expect. Tools like Metaceller help there. Since I am using, I reduced my 'configuration-fixing-time' by half. Johan
Perhaps I was not really clear. My argument was against different _versions_ of a ConfigurationOfXXX in different (metacello-|catalog-)repositories. This will create a real mess because you _will_ get identical package versions of the ConfigurationOfXXX package in your package cache, leading to strange load errors (Metacello not finding a version, loading a wrong version, etc..) Keeping a _copy_ of the ConfigurationOfXXX in different metacello repositories is the way to go. Making different branches of ConfigurationOfXXX in the different metacello repositories is the way to versioning hell. At least, that is what I understood you intended to do? Take a look at ConfigurationOfZinc, ConfigurationOfSeaside3, ... they have a _single_ branch of their ConfigurationOfXXX for all platforms and these are copied everywhere for reference. Johan On 22 Mar 2014, at 21:51, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2014-03-22 21:27 GMT+01:00 Johan Brichau <johan@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.nice@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 <johan@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.nice@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?
participants (3)
-
Johan Brichau -
Nicolas Cellier -
Pharo4Stef