Delegating to another ConfigurationOf

I often have extensions to other people's projects that I want to load every time I load their project. I keep the extensions packaged to mirror the package structure of the underlying project. For example, PetitParser has a PetitParser package, so I have PetitParserSpd, which contains all the extension methods to classes in the PetitParser package.

I am really just making small tweaks to an existing project that, for whatever reason, are not being integrated into that project, so I don't want to redefine everything (e.g. groups). How can I say "delegate all operations to the PetitParser config, but declare these additional dependencies"?

I want to do something like:
        spec project: 'PetitParser' with: [
                spec
                        className: 'ConfigurationOfPetitParser';
                        version: #'stable';
                        repository: 'http://source.lukas-renggli.ch/petit' ].
                spec
                        package: 'PetitParserSpd';
                        package: 'PetitParser' with: [ spec includes: #('PetitParserSpd') ] ].

But:
* it doesn't work... I get "Error: The project spec 'PetitParser' in project ConfigurationOfPetitParserSpd has imcompatible specs." (no difference whether I put the package: sends in or out of the #project:with:)
* I'd have to redefine all the groups from ConfigurationOfPetitParser

I feel like I want to subclass ConfigurationOfPetitParser, but obviously that doesn't fit into the Metacello world very well e.g. I load my config and the superclass will not be there...

How should I proceed?

Thanks,
Sean

If you use your own configuration (say ConfigurationOfPetitParserSpd) as a wrapper and you use the Metacello Preview version you can get close with something like this (assuming that a BaselineOfPetit has been created):

  version15: spec
    <version: '1.5.0'>
    spec
        for: #'common'
        do: [
            spec blessing: #'development'.
            spec description: ''.
            spec
                baseline: 'PetitParser config'
                with: [
                    spec
                        className: 'BaselineOfPetitParser';
                        repository: 'http://source.lukas-renggli.ch/petit' ].
            spec import: 'PetitParser config'.
            spec package: 'PetitParserSpd' with: [ spec requires: 'PetitParser' ] ]

The `import:` message arranges for any 'undefined names' to be resolved by the BaselineOfPetitParser.

In this case 'PetitParser' isn't defined, so 'PetitParser' is added to the `loads:` list for 'PetitParser config'. In essence it is doing a `project:copyFrom:with:` on demand.

At the moment the `import:` message can only be used with a BaselineOf, but I don't think there's a good reason to restrict the `import:` message to only BaselineOf ... So you should be able to do this against the existing configuration:

  version15: spec
    <version: '1.5.0'>
    spec
        for: #'common'
        do: [
            spec blessing: #'development'.
            spec description: ''.
            spec
                configuration: 'PetitParser config'
                with: [
                    spec
                        className: 'ConfigurationOfPetitParser';
                        repository: 'http://source.lukas-renggli.ch/petit' ].
            spec import: 'PetitParser config'.
            spec package: 'PetitParserSpd' with: [ spec requires: 'PetitParser' ] ]


If this level of functionality would be useful to you, then I can make that change for the next release of the Preview...

If you need something more sophisticated I can look into how difficult it would be to do something closer to the type of thing you get with the `<version:imports:>` pragma ...

Dale
 
----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Monday, August 6, 2012 8:18:20 PM
| Subject: [Metacello] Delegating to another ConfigurationOf
|
| I often have extensions to other people's projects that I want to
| load every
| time I load their project. I keep the extensions packaged to mirror
| the
| package structure of the underlying project. For example, PetitParser
| has a
| PetitParser package, so I have PetitParserSpd, which contains all the
| extension methods to classes in the PetitParser package.
|
| I am really just making small tweaks to an existing project that, for
| whatever reason, are not being integrated into that project, so I
| don't want
| to redefine everything (e.g. groups). How can I say "delegate all
| operations
| to the PetitParser config, but declare these additional
| dependencies"?
|
| I want to do something like:
| spec project: 'PetitParser' with: [
| spec
| className: 'ConfigurationOfPetitParser';
| version: #'stable';
| repository: 'http://source.lukas-renggli.ch/petit' ].
| spec
| package: 'PetitParserSpd';
| package: 'PetitParser' with: [ spec includes: #('PetitParserSpd')
| ] ].
|
| But:
| * it doesn't work... I get "Error: The project spec 'PetitParser' in
| project
| ConfigurationOfPetitParserSpd has imcompatible specs." (no difference
| whether I put the package: sends in or out of the #project:with:)
| * I'd have to redefine all the groups from ConfigurationOfPetitParser
|
| I feel like I want to subclass ConfigurationOfPetitParser, but
| obviously
| that doesn't fit into the Metacello world very well e.g. I load my
| config
| and the superclass will not be there...
|
| How should I proceed?
|
| Thanks,
| Sean
|
|
|
| --
| View this message in context:
| http://forum.world.st/Delegating-to-another-ConfigurationOf-tp4643407.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

I don't think there's a good reason to restrict the `import:` message to only BaselineOf ... So you should be able to do this against the existing configuration:
...
            spec
                configuration: 'PetitParser config'
                with: [
                    spec
                        className: 'ConfigurationOfPetitParser';
                        repository: 'http://source.lukas-renggli.ch/petit' ].
            spec import: 'PetitParser config'.
            spec package: 'PetitParserSpd' with: [ spec requires: 'PetitParser' ] ]

That looks like what I need. The only difference is that I think I want to say:
  spec package: 'PetitParser' with: [ spec includes: 'PetitParserSpd' ]
so that my extension package gets loaded if and only if the underlying package does

If I'm understanding, I'll be able to refer to objects from ConfigurationOfPetitParser directly, like I can say:
  ConfigurationOfPetitParserSpd "(my custom config)" project stableVersion load: 'Core'
and it will load the core group of ConfigurationOfPetitParser even though I'm not defining 'Core' in the extension config, and if that includes the PetitParser package, PetitParserSpd will get pulled in?

What about the version of ConfigurationOfPetitParser? If I'm importing ConfigurationOfPetitParser, do I specify a specific version to import into my v. 1.5?

Ultimately, I guess the BaselineOf version will be enough, but adding it to #configuration:with: is necessary until existing configs are all updated...

Thanks!
Sean

Dale Henrichs wrote

I don't think there's a good reason to restrict the `import:` message to only BaselineOf

[ENH]: Extend #import: from baselines to configurations
https://github.com/dalehenrich/metacello-work/issues/105

Dale, not sure if you saw this...

Sean P. DeNigris wrote

If I'm understanding, I'll be able to refer to objects from ConfigurationOfPetitParser directly, like I can say:
  ConfigurationOfPetitParserSpd "(my custom config)" project stableVersion load: 'Core'
and it will load the core group of ConfigurationOfPetitParser even though I'm not defining 'Core' in the extension config, and if that includes the PetitParser package, PetitParserSpd will get pulled in?

What about the version of ConfigurationOfPetitParser? If I'm importing ConfigurationOfPetitParser, do I specify a specific version to import into my v. 1.5?

Yeah, I missed the other questions ... I've been mulling over the request to be able to do an #includes: as in:

    spec package: 'PetitParser' with: [ spec includes: 'PetitParserSpd' ]

This particular bit complicates things quite a bit ... quite a bit...

The implementation of #import: currently assumes that all `undefined names` can be satisfied by the `imported project` and the `undefined names` are simply added to the #loads: list.

In:

  spec package: 'PetitParserSpd' with: [ spec requires: 'PetitParser' ].

'PetitParser' is an `undefined name` (i.e. it does not show up as the name of a project, package or group).

In:

  spec package: 'PetitParser' with: [ spec includes: 'PetitParserSpd' ]

'PetitParser' is _defined_, so 'PetitParser' is not imported.... Mingling the two name spaces (which is what would be required) is much more difficult to accomplish ... the technology exists for doing a merge, but if the two projects are merged, the unique identity that that the two projects are supposed to have is lost and .... well if I had a good answer, I'd have responded by now:)

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Friday, August 10, 2012 11:29:23 AM
| Subject: [Metacello] Re: Delegating to another ConfigurationOf
|
| Dale, not sure if you saw this...
|
|
| Sean P. DeNigris wrote
| >
| > If I'm understanding, I'll be able to refer to objects from
| > ConfigurationOfPetitParser directly, like I can say:
| >   ConfigurationOfPetitParserSpd "(my custom config)" project
| >   stableVersion
| > load: 'Core'
| > and it will load the core group of ConfigurationOfPetitParser even
| > though
| > I'm not defining 'Core' in the extension config, and if that
| > includes the
| > PetitParser package, PetitParserSpd will get pulled in?
| >
| > What about the version of ConfigurationOfPetitParser? If I'm
| > importing
| > ConfigurationOfPetitParser, do I specify a specific version to
| > import into
| > my v. 1.5?
| >
|
|
|
| --
| View this message in context:
| http://forum.world.st/Delegating-to-another-ConfigurationOf-tp4643407p4643796.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Friday, August 10, 2012 11:29:23 AM
| Subject: [Metacello] Re: Delegating to another ConfigurationOf
|
| Dale, not sure if you saw this...
|
|
| Sean P. DeNigris wrote
| >
| > If I'm understanding, I'll be able to refer to objects from
| > ConfigurationOfPetitParser directly, like I can say:
| >   ConfigurationOfPetitParserSpd "(my custom config)" project
| >   stableVersion
| > load: 'Core'
| > and it will load the core group of ConfigurationOfPetitParser even
| > though
| > I'm not defining 'Core' in the extension config, and if that
| > includes the
| > PetitParser package, PetitParserSpd will get pulled in?

If you're intent is is use the #includes: variant, then the answer is that does not work now and probably won't work in the future..

If you insist on using #includes: I think that your best be is to copy the PetitParser configuration ... you're really extending the PetitParser project using #includes.

If on the other hand, you are simply interested in getting PetitParserSpd loaded without the tight coupling that #includes: implies, then that can be arranged ...

| >
| > What about the version of ConfigurationOfPetitParser? If I'm
| > importing
| > ConfigurationOfPetitParser, do I specify a specific version to
| > import into
| > my v. 1.5?
| >

Not quite sure what you are asking here ... some more detailed sample spec code would help me understand what you think you are asking and then I can I can fix the code to show you what will work...

Dale

Dale Henrichs wrote

you're really extending the PetitParser project

Yes! That is what I was trying to get across.

My use case is: for just about every project I use, I have fixes and extensions that I want to include with them. They are generally useful, so I don't want to package them with the projects that load the extensions. It's basically a mini-fork of the project. For the fixes, it's usually just in the interim until they are integrated (although if the project is abandoned, maybe not; but then again in that case I could probably just fork). For the extensions, sometimes the project maintainers don't think they're as wonderful as I do, so they will never be integrated.

Now, I don't want to go through the hassle of forking all the ConfigurationOfUnderlyingProject's, both because it's time consuming and because I would lose part of the value of Metacello in that, instead of relying on Metacello to pull down the latest config, I would become the config maintainer of every project I use and have to monitor and integrate the underlying configs as they evolve.

Metaphorically, I'm looking to subclass the underlying config, but obviously I can't because the subclass will not be there when my config class gets loaded. But the behavior I'm looking for is that my config can be interacted with as if it was the underlying config, but my extensions will automatically get loaded if appropriate because my config extends the baseline.

Probably just dreaming, but this would be /very/ useful to me. Thanks for thinking this through with me...

Sean

Sean,

Okay I get what you're trying to do and the new Metacello Scripting APi may be just the ticket for you ...

Once a configuration is loaded into your image, the scripting api will not reload a configuration ... the only way to refresh your configuration is to use the `get` command.

So...if you create your own versions of the configurations of projects that you've forked and then load those configurations into your image then the scripting api will use your configurations instead of the official ones for the projects ... You can load all of the configurations or your "forked" projects like this (assuming you are keeping your forked configurations in a separate repo):

  Metacallo new
    configuration: [:spec | true ]'
    repository: '<spec private forked repo>';
    get.

Another alternative is to use the `lock` command to make sure that your version of the each of the "forked" projects is used (an error is thrown if an attempt is made to downgrade or upgrade the project during a load ... the error is thrown during the fetch phase so no loads should have been performed). To lock a project you can do the following:

  Metacello new
    configuration: 'PetitParser';
    version: #stable;
    repository: '<spec private forked repo>';
    lock.

When you use the `lock` command you don't need to pre-load the configuration. When the scripting api encounters a reference to 'PetitParser' your configuration will be loaded and if a version is required other than #stable, and error will be thrown ... You can then use the `onDowngrade:` or 'onUpgrade:` messages to avoid the lock error by explicitly disallowing the upgrade/downgrade ...

This behavior was explicitly introduced into the scripting api to allow folks to "fork" projects, so now that it's clear what you are doing I will be interested to make sure that everything works correctly in support of what you are trying to do!

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Friday, August 10, 2012 4:14:11 PM
| Subject: [Metacello] Re: Delegating to another ConfigurationOf
|
|
| Dale Henrichs wrote
| >
| > you're really extending the PetitParser project
|
| Yes! That is what I was trying to get across.
|
| My use case is: for just about every project I use, I have fixes and
| extensions that I want to include with them. They are generally
| useful, so I
| don't want to package them with the projects that load the
| extensions. It's
| basically a mini-fork of the project. For the fixes, it's usually
| just in
| the interim until they are integrated (although if the project is
| abandoned,
| maybe not; but then again in that case I could probably just fork).
| For the
| extensions, sometimes the project maintainers don't think they're as
| wonderful as I do, so they will never be integrated.
|
| Now, I don't want to go through the hassle of forking all the
| ConfigurationOfUnderlyingProject's, both because it's time consuming
| and
| because I would lose part of the value of Metacello in that, instead
| of
| relying on Metacello to pull down the latest config, I would become
| the
| config maintainer of every project I use and have to monitor and
| integrate
| the underlying configs as they evolve.
|
| Metaphorically, I'm looking to subclass the underlying config, but
| obviously
| I can't because the subclass will not be there when my config class
| gets
| loaded. But the behavior I'm looking for is that my config can be
| interacted
| with as if it was the underlying config, but my extensions will
| automatically get loaded if appropriate because my config extends the
| baseline.
|
| Probably just dreaming, but this would be /very/ useful to me. Thanks
| for
| thinking this through with me...
|
| Sean
|
|
|
|
|
| --
| View this message in context:
| http://forum.world.st/Delegating-to-another-ConfigurationOf-tp4643407p4643817.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

So...if you create your own versions of the configurations of projects that you've forked

So it sounds like my only option right now is to fork the configuration for each project I use (which I was hoping to avoid)...

Although import: of a config might offer some workaround...
If the baseline of ConfigurationOfPetitParser contained:
  group: 'Core' with: #('PetitParser' 'PetitAnalyzer' );
And I wrote:
  ConfigurationOfPetitParserSpd>>baselineXx:
    ...
    spec
        for: #'common'
        do: [
            spec blessing: #'development'.
            spec description: ''.
            spec
                configuration: 'PetitParser config'
                with: [
                    spec
                        className: 'ConfigurationOfPetitParser';
                        repository: 'http://source.lukas-renggli.ch/petit' ].
            spec import: 'PetitParser config'.

Would I be able to do "ConfigurationOfPetitParserSpd project stableVersion load: 'Core'" and would that load the 'Core' group of ConfigurationOfPetitParser?

If so, I could check in a post-load doIt what got loaded and load the appropriate extension packages, e.g.:
  ...
  spec postLoadDoIt: #afterLoad:with:.
  ...
and then:
  afterLoad: loader with: spec

        self loadDirective packageDirectivesDo: [ :e | (self extendedPackageNames includes: e packageName) ifTrue: [ self loadExtensionsForPackageNamed: e packageName ] ].

If all this sounds possible, should #loadExtensionsForPackageNamed: kick off a new Metacello load of only extension packages, or use Gofer directly? (The structure will not be more complicated than "one extension package per package of the underlying project")

Thanks a lot. I know this is complicated, but it's the lesser of two evils compared to forking and maintaining a config for every project I use, esp. until we all convert to github ;-) j/k...

Sean

Sounds like you almost want (but perhaps this would be getting outside
the scope of Metacello)...

Metacello image
    configuration: 'Sample'
    saveCustomizations: 'someFile.someExt'

which saves only the changes from the original current Configuration, or
allows you to interactively choose which changes to save,
followed by....

Metacello new
    configuration: 'Sample'
    loadCustomizations: 'someFile.someExt'

which automatically kicks off Monticello merge function.

or perhaps in just one step...

Metacello new
    configuration: 'Sample'
    keepCustomizations.

cheers -ben


Dale Henrichs wrote:

Sean,

I hate to suggest using Gofer, but I'm also not sure what impact a Metacello load as a postload action would have - you are bypassing a whole bunch of stuff ...

Since you are willing to loosen the coupling between your extension package and the main project I would think that you could do the following and get the same effect without SUBVERTING (said with a  smile) Metacello:

  ConfigurationOfPetitParserSpd>>baselineXx:
    ...
    spec
        for: #'common'
        do: [
            spec blessing: #'development'.
            spec description: ''.
            spec
                configuration: 'PetitParser config'
                with: [
                    spec
                        className: 'ConfigurationOfPetitParser';
                        repository: 'http://source.lukas-renggli.ch/petit'].
            spec import: 'PetitParser config'.
            spec package: 'PetitParserSpd' with: [ spec requires: 'Core' ].
            spec group:  'MyCore' with: #('PetitParserSpd' 'Core')] ].

You could then load 'MyCore' instead of 'Core' and get the same effect as your post load expression while still using Metacello to do the package loading...

Does this work for you?

Dale
----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, August 11, 2012 11:52:15 AM
| Subject: [Metacello] Re: Delegating to another ConfigurationOf
|
|
| Dale Henrichs wrote
| >
| > So...if you create your own versions of the configurations of
| > projects
| > that you've forked
|
| So it sounds like my only option right now is to fork the
| configuration for
| each project I use (which I was hoping to avoid)...
|
| Although import: of a config might offer some workaround...
| If the baseline of ConfigurationOfPetitParser contained:
|   group: 'Core' with: #('PetitParser' 'PetitAnalyzer' );
| And I wrote:
|   ConfigurationOfPetitParserSpd>>baselineXx:
|     ...
|     spec
|         for: #'common'
|         do: [
|             spec blessing: #'development'.
|             spec description: ''.
|             spec
|                 configuration: 'PetitParser config'
|                 with: [
|                     spec
|                         className: 'ConfigurationOfPetitParser';
|                         repository:
|                         'http://source.lukas-renggli.ch/petit'
| ].
|             spec import: 'PetitParser config'.
|
| Would I be able to do "ConfigurationOfPetitParserSpd project
| stableVersion
| load: 'Core'" and would that load the 'Core' group of
| ConfigurationOfPetitParser?
|
| If so, I could check in a post-load doIt what got loaded and load the
| appropriate extension packages, e.g.:
|   ...
|   spec postLoadDoIt: #afterLoad:with:.
|   ...
| and then:
|   afterLoad: loader with: spec
|
| self loadDirective packageDirectivesDo: [ :e | (self
| extendedPackageNames
| includes: e packageName) ifTrue: [ self
| loadExtensionsForPackageNamed: e
| packageName ] ].
|
| If all this sounds possible, should #loadExtensionsForPackageNamed:
| kick off
| a new Metacello load of only extension packages, or use Gofer
| directly? (The
| structure will not be more complicated than "one extension package
| per
| package of the underlying project")
|
| Thanks a lot. I know this is complicated, but it's the lesser of two
| evils
| compared to forking and maintaining a config for every project I use,
| esp.
| until we all convert to github ;-) j/k...
|
| Sean
|
|
|
| --
| View this message in context:
| http://forum.world.st/Delegating-to-another-ConfigurationOf-tp4643407p4643849.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Ben,

I think that "taking ownership" of the ConfigurationOf and editing it to customize the config along with the suggested use of `lock` and `get` is the preferred route while staying within the bounds of Metacello ...

Dale

----- Original Message -----
| From: "Ben Coman" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, August 11, 2012 4:24:37 PM
| Subject: Re: [Metacello] Re: Delegating to another ConfigurationOf
|
| Sounds like you almost want (but perhaps this would be getting
| outside
| the scope of Metacello)...
|
| Metacello image
|     configuration: 'Sample'
|     saveCustomizations: 'someFile.someExt'
|
| which saves only the changes from the original current Configuration,
| or
| allows you to interactively choose which changes to save,
| followed by....
|
| Metacello new
|     configuration: 'Sample'
|     loadCustomizations: 'someFile.someExt'
|
| which automatically kicks off Monticello merge function.
|
| or perhaps in just one step...
|
| Metacello new
|     configuration: 'Sample'
|     keepCustomizations.
|
| cheers -ben
|
|
| Dale Henrichs wrote:
| > Sean,
| >
| > Okay I get what you're trying to do and the new Metacello Scripting
| > APi may be just the ticket for you ...
| >
| > Once a configuration is loaded into your image, the scripting api
| > will not reload a configuration ... the only way to refresh your
| > configuration is to use the `get` command.
| >
| > So...if you create your own versions of the configurations of
| > projects that you've forked and then load those configurations
| > into your image then the scripting api will use your
| > configurations instead of the official ones for the projects ...
| > You can load all of the configurations or your "forked" projects
| > like this (assuming you are keeping your forked configurations in
| > a separate repo):
| >
| >   Metacallo new
| >     configuration: [:spec | true ]'
| >     repository: '<spec private forked repo>';
| >     get.
| >
| > Another alternative is to use the `lock` command to make sure that
| > your version of the each of the "forked" projects is used (an
| > error is thrown if an attempt is made to downgrade or upgrade the
| > project during a load ... the error is thrown during the fetch
| > phase so no loads should have been performed). To lock a project
| > you can do the following:
| >
| >   Metacello new
| >     configuration: 'PetitParser';
| >     version: #stable;
| >     repository: '<spec private forked repo>';
| >     lock.
| >
| > When you use the `lock` command you don't need to pre-load the
| > configuration. When the scripting api encounters a reference to
| > 'PetitParser' your configuration will be loaded and if a version
| > is required other than #stable, and error will be thrown ... You
| > can then use the `onDowngrade:` or 'onUpgrade:` messages to avoid
| > the lock error by explicitly disallowing the upgrade/downgrade ...
| >
| > This behavior was explicitly introduced into the scripting api to
| > allow folks to "fork" projects, so now that it's clear what you
| > are doing I will be interested to make sure that everything works
| > correctly in support of what you are trying to do!
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Sean P. DeNigris" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Friday, August 10, 2012 4:14:11 PM
| > | Subject: [Metacello] Re: Delegating to another ConfigurationOf
| > |
| > |
| > | Dale Henrichs wrote
| > | >
| > | > you're really extending the PetitParser project
| > |
| > | Yes! That is what I was trying to get across.
| > |
| > | My use case is: for just about every project I use, I have fixes
| > | and
| > | extensions that I want to include with them. They are generally
| > | useful, so I
| > | don't want to package them with the projects that load the
| > | extensions. It's
| > | basically a mini-fork of the project. For the fixes, it's usually
| > | just in
| > | the interim until they are integrated (although if the project is
| > | abandoned,
| > | maybe not; but then again in that case I could probably just
| > | fork).
| > | For the
| > | extensions, sometimes the project maintainers don't think they're
| > | as
| > | wonderful as I do, so they will never be integrated.
| > |
| > | Now, I don't want to go through the hassle of forking all the
| > | ConfigurationOfUnderlyingProject's, both because it's time
| > | consuming
| > | and
| > | because I would lose part of the value of Metacello in that,
| > | instead
| > | of
| > | relying on Metacello to pull down the latest config, I would
| > | become
| > | the
| > | config maintainer of every project I use and have to monitor and
| > | integrate
| > | the underlying configs as they evolve.
| > |
| > | Metaphorically, I'm looking to subclass the underlying config,
| > | but
| > | obviously
| > | I can't because the subclass will not be there when my config
| > | class
| > | gets
| > | loaded. But the behavior I'm looking for is that my config can be
| > | interacted
| > | with as if it was the underlying config, but my extensions will
| > | automatically get loaded if appropriate because my config extends
| > | the
| > | baseline.
| > |
| > | Probably just dreaming, but this would be /very/ useful to me.
| > | Thanks
| > | for
| > | thinking this through with me...
| > |
| > | Sean
| > |
| > |
| > |
| > |
| > |
| > | --
| > | View this message in context:
| > | http://forum.world.st/Delegating-to-another-ConfigurationOf-tp4643407p4643817.html
| > | Sent from the Metacello mailing list archive at Nabble.com.
| > |
| >
| >  
|
|

Sean,

I'm not sure why "forking the project" by taking "ownership" of the ConfigurationOf is not an acceptable option for you ... you can use a "custom" version (1.7-spd) to isolate your changes form the main-line configuration and make it relatively easy to merge any future config changes into your version ...

Then the 'lock' and 'get' commands would allow you to use your handiwork...

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, August 11, 2012 11:52:15 AM
| Subject: [Metacello] Re: Delegating to another ConfigurationOf
|
|
| Dale Henrichs wrote
| >
| > So...if you create your own versions of the configurations of
| > projects
| > that you've forked
|
| So it sounds like my only option right now is to fork the
| configuration for
| each project I use (which I was hoping to avoid)...
|
| Although import: of a config might offer some workaround...
| If the baseline of ConfigurationOfPetitParser contained:
|   group: 'Core' with: #('PetitParser' 'PetitAnalyzer' );
| And I wrote:
|   ConfigurationOfPetitParserSpd>>baselineXx:
|     ...
|     spec
|         for: #'common'
|         do: [
|             spec blessing: #'development'.
|             spec description: ''.
|             spec
|                 configuration: 'PetitParser config'
|                 with: [
|                     spec
|                         className: 'ConfigurationOfPetitParser';
|                         repository:
|                         'http://source.lukas-renggli.ch/petit'
| ].
|             spec import: 'PetitParser config'.
|
| Would I be able to do "ConfigurationOfPetitParserSpd project
| stableVersion
| load: 'Core'" and would that load the 'Core' group of
| ConfigurationOfPetitParser?
|
| If so, I could check in a post-load doIt what got loaded and load the
| appropriate extension packages, e.g.:
|   ...
|   spec postLoadDoIt: #afterLoad:with:.
|   ...
| and then:
|   afterLoad: loader with: spec
|
| self loadDirective packageDirectivesDo: [ :e | (self
| extendedPackageNames
| includes: e packageName) ifTrue: [ self
| loadExtensionsForPackageNamed: e
| packageName ] ].
|
| If all this sounds possible, should #loadExtensionsForPackageNamed:
| kick off
| a new Metacello load of only extension packages, or use Gofer
| directly? (The
| structure will not be more complicated than "one extension package
| per
| package of the underlying project")
|
| Thanks a lot. I know this is complicated, but it's the lesser of two
| evils
| compared to forking and maintaining a config for every project I use,
| esp.
| until we all convert to github ;-) j/k...
|
| Sean
|
|
|
| --
| View this message in context:
| http://forum.world.st/Delegating-to-another-ConfigurationOf-tp4643407p4643849.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

I'm not sure why "forking the project" by taking "ownership" of the ConfigurationOf is not an acceptable option for you ...

Probably being stubborn more than anything ;)

It just seems like monitoring a project for changes to the config is a high-price to pay just to declare one or two additional package dependencies (if everyone was on github, it would be much easier, but now it requires polling the repository, reviewing changes, merging new versions, and then updating the customizations).

It seems like making minor tweaks to an existing configuration will be a common use case. Right now, the api doesn't seem to provide any functionality there. Am I the only one with this need?

Thanks for all the discussion. I think the #import: on a config will get me close enough if that seems more reasonable from your end...

Sean