Metacello Projects: one canonical config/repo for all platforms
There are two things that have bothered me about our use of Metacello, but I couldn't explain exactly why until now. These are two guidelines that I think are important: 1. ConfigurationOfMyProject should live at repoOfMyProject. Any MetaRepoForXyz should only be a copy of this config 2. Platform-specific config sections are not optional Without these two things, we're back in Babbel. Here's why... I wrote a configuration that depended on several well-known projects. Someone had very generously updated the configs and placed them in metaReposForXyz (e.g. http://squeaksource.com/MetacelloRepository), so that's the repo I referenced in my config. In the meantime, the same was done for later Pharo versions (MetaRepoFor30, etc). Now I'm stuck - either I have to manually manage platform variations of project dependencies myself, or settle to only ever have my config work in latest Pharo - but I'll still have to update the repo url for each new version which is a pain. Of course I understand that editing directly in a MetaRepo is very tempting (and I've done it myself), it is a quick and dirty hack that subverts much of the value of Metacello. Of course, there are limits to our ability to follow #1, like where we don't have access to the repo, but it doesn't even seem like we're trying. And there are limits to #2 like maybe we don't know how to get it to work in Squeak, but we can at least keep Pharo versions working. I have been using Mariano's workflow of using latest Pharo as the reference implementation and adding compatibility shims for previous versions. If we don't take an extra moment to do it right, we simply push this work onto users. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-Projects-one-canonical-config-repo-for-all-p... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Thu, Aug 7, 2014 at 9:40 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
There are two things that have bothered me about our use of Metacello, but I couldn't explain exactly why until now. These are two guidelines that I think are important: 1. ConfigurationOfMyProject should live at repoOfMyProject. Any MetaRepoForXyz should only be a copy of this config 2. Platform-specific config sections are not optional
Makes a lot of sense and I agree. Dale
Ben and Sean, After a bit more thought, I believe that it should be okay to make copies, but there does need to be a single primary repository where the correct and latest configuration can be found. Putting copies of configurations into repositories to make project discovery easier is a good use of copies. Copies are also useful when creating mirror repos.... But one must be able to determine the location of the canonical repository for the configuration. If the configuration were always co-located with the packages then it would relatively easy to figure out where to find the newest and 'correctest' configuration. The canonical location should ALWAYS be used in project references. Dale On Thu, Aug 7, 2014 at 8:30 PM, Ben Coman <btc@openinworld.com> wrote:
Dale Henrichs wrote:
On Thu, Aug 7, 2014 at 9:40 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
There are two things that have bothered me about our use of Metacello, but I couldn't explain exactly why until now. These are two guidelines that I think are important: 1. ConfigurationOfMyProject should live at repoOfMyProject. Any MetaRepoForXyz should only be a copy of this config 2. Platform-specific config sections are not optional
Makes a lot of sense and I agree.
Dale
I feel similar. Not that I've published any Configurations yet, but looking in from the outside the current process always made me uneasy that is violates my general principle of DON'T MAKE COPIES.
Maybe the MetaRepoForXyz should not contain any ConfigurationOfMyProject at all, but a CatalogOfMyProject (or MetaOfMyProject) which simply points to the ConfigurationOfMyProject in the project repo.
cheers -ben
Dale Henrichs-3 wrote
After a bit more thought, I believe that it should be okay to make copies
That sounds right. For instance, the MetaRepoForPharo123 repos would be configs certified to work in Pharo 123 that have been copied from the canonical repo. Of course what it feels like we really want is a catalog a la SqueakMap, but copying configs works for now. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-Projects-one-canonical-config-repo-for-all-p... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
agreed On Thu, Aug 7, 2014 at 11:17 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Dale Henrichs-3 wrote
After a bit more thought, I believe that it should be okay to make copies
That sounds right. For instance, the MetaRepoForPharo123 repos would be configs certified to work in Pharo 123 that have been copied from the canonical repo. Of course what it feels like we really want is a catalog a la SqueakMap, but copying configs works for now.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-Projects-one-canonical-config-repo-for-all-p... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 08 Aug 2014, at 06:16, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Ben and Sean,
After a bit more thought, I believe that it should be okay to make copies, but there does need to be a single primary repository where the correct and latest configuration can be found.
Putting copies of configurations into repositories to make project discovery easier is a good use of copies. Copies are also useful when creating mirror repos....
But one must be able to determine the location of the canonical repository for the configuration.
If the configuration were always co-located with the packages then it would relatively easy to figure out where to find the newest and 'correctest' configuration.
The canonical location should ALWAYS be used in project references.
But can't Metacello help there ? I mean, each configuration, no matter where it is copied/located is the same and knows its canonical repository, right ? So all that is needed is a kind of double-check, or following the reference. BTW, doesn't Metacello not do some latest version checking already ?
Dale
On Thu, Aug 7, 2014 at 8:30 PM, Ben Coman <btc@openinworld.com> wrote: Dale Henrichs wrote:
On Thu, Aug 7, 2014 at 9:40 AM, Sean P. DeNigris <sean@clipperadams.com> wrote: There are two things that have bothered me about our use of Metacello, but I couldn't explain exactly why until now. These are two guidelines that I think are important: 1. ConfigurationOfMyProject should live at repoOfMyProject. Any MetaRepoForXyz should only be a copy of this config 2. Platform-specific config sections are not optional
Makes a lot of sense and I agree.
Dale
I feel similar. Not that I've published any Configurations yet, but looking in from the outside the current process always made me uneasy that is violates my general principle of DON'T MAKE COPIES.
Maybe the MetaRepoForXyz should not contain any ConfigurationOfMyProject at all, but a CatalogOfMyProject (or MetaOfMyProject) which simply points to the ConfigurationOfMyProject in the project repo.
cheers -ben
On Fri, Aug 8, 2014 at 3:54 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 08 Aug 2014, at 06:16, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Ben and Sean,
After a bit more thought, I believe that it should be okay to make copies, but there does need to be a single primary repository where the correct and latest configuration can be found.
Putting copies of configurations into repositories to make project discovery easier is a good use of copies. Copies are also useful when creating mirror repos....
But one must be able to determine the location of the canonical repository for the configuration.
If the configuration were always co-located with the packages then it would relatively easy to figure out where to find the newest and 'correctest' configuration.
The canonical location should ALWAYS be used in project references.
But can't Metacello help there ?
I mean, each configuration, no matter where it is copied/located is the same and knows its canonical repository, right ?
So all that is needed is a kind of double-check, or following the reference.
BTW, doesn't Metacello not do some latest version checking already ?
Sven,
In a project reference, the developer specifies the repository from which the configuration should be loaded: spec project: 'Zinc Project' with: [ spec versionString: #'stable'; className: 'ConfigurationOfZincHTTPComponents'; repository: 'http://mc.stfx.eu/ZincHTTPComponents' ]. In the above case, the canonical repository for Zinc is being used, but a developer can use a different repository like http://squeaksource.com/MetacelloRepository. Metacello's job is to do what the developer specifies. The developer may have perfectly good reasons for specifying a different location than the canonical repository: - critical bug fix to configuration, but no write access to canonical repo - private fork of project ... - etc. Metacello cannot second guess the developer when it comes to loading packages:) Sean is referring to the fact that some configurations are not present in the repository where the packages are located and they should be. Also there are cases where the generic *MetacelloRepository* is used in a project reference when the canonical location should be. Dale
participants (4)
-
Ben Coman -
Dale Henrichs -
Sean P. DeNigris -
Sven Van Caekenberghe