Can Metacello fail when we have inconsistent dependencies?

Hi,

Patrik,

Your questions are feedback are much appreciated.

comments embedded...

----- Original Message -----
| From: "Patrik Sundberg" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 2:04:51 PM
| Subject: [Metacello] Can Metacello fail when we have inconsistent dependencies?
|
| Hi,
|
|
| I was reading the Metacello PBE2 chapter (excellent!)

Kudos to Stef and Mariano for their work on documenting Metacello!

| and I see that
| if we have Project A depending on B and C, and B and C depends on D
| but not the same version of D, then the latest version that either B
| or C depends on will be used. Is there a way to make the load
| fail/raise instead of implicitly picking one version?

Yes, using the scripting api you can get involved in this decision as follows:

  Metacello new
    configuration: 'A';
    version: #stable;
    onUpgrade: [:ex | ex disallow "default is allow" ];
    onDowngrade: [:ex | ex allow "default is disallow" ];
    load.

The scripting API records the versions of projects that are loaded into the image, so when doing the load, the first version B encountered will not cause an exception to be raised (an onLoad: could be added if there's a use case), but when the second (different) version of B is encountered the onUpgrade/Downgrade/Conflict exception will be raised and you will have an opportunity to "decide".

|
|
| In my current ruby workflow bundler will fail in those instances
| since it's undefined what the right thing to do is, and then I tend
| to fork the project's I depend on and make them "compatible",
| possibly issuing pull requests back upstream and going back to using
| upstream once they're back in sync. With the github ease of forking,
| keeping a fork in sync with upstream etc that's a pretty good
| workflow I've found and looks like it'll be possible to stick to it
| in smalltalk talk land - but would like to get notified of the
| inconsistent dependencies so one doesn't have to inspect that by
| hand via debug method #record.

So you can use the following to halt in case of change:

  Metacello new
    configuration: 'A';
    version: #stable;
    onUpgrade: [:ex | self halt ];
    onDowngrade: [:ex | self halt ];
    load.

and arrange for errors ...

I am also providing a `lock` command that allows you to lock down a version of a particular project. An error will be thrown if an attempt is made to load a different version. The `lock` facility is primarily aimed at the use case where you've got a particular version checked out with git and you want to ensure that you are always using the checkout out version.

For your particular use case, you would probably want to `register` your fork of project B so that your fork would always be used for that project ... Given this use case, I would be willing to add a `register` command...

The point of the preview release is to fine tune the API and provide the kind of functionality required by real world use cases.

I am fully prepared to revisit the whole api, if real world use points in different directions ...

Dale

On Wednesday, July 25, 2012 3:56:17 PM UTC+1, Dale wrote:

Patrik,

Your questions are feedback are much appreciated.

comments embedded...

----- Original Message -----
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 2:04:51 PM
| Subject: [Metacello] Can Metacello fail when we have inconsistent dependencies?
|
| Hi,
|
|
| I was reading the Metacello PBE2 chapter (excellent!)

Kudos to Stef and Mariano for their work on documenting Metacello!

| and I see that
| if we have Project A depending on B and C, and B and C depends on D
| but not the same version of D, then the latest version that either B
| or C depends on will be used. Is there a way to make the load
| fail/raise instead of implicitly picking one version?

Yes, using the scripting api you can get involved in this decision as follows:

  Metacello new
    configuration: 'A';
    version: #stable;
    onUpgrade: [:ex | ex disallow "default is allow" ];
    onDowngrade: [:ex | ex allow "default is disallow" ];
    load.

The scripting API records the versions of projects that are loaded into the image, so when doing the load, the first version B encountered will not cause an exception to be raised (an onLoad: could be added if there's a use case), but when the second (different) version of B is encountered the onUpgrade/Downgrade/Conflict exception will be raised and you will have an opportunity to "decide".

|
|
| In my current ruby workflow bundler will fail in those instances
| since it's undefined what the right thing to do is, and then I tend
| to fork the project's I depend on and make them "compatible",
| possibly issuing pull requests back upstream and going back to using
| upstream once they're back in sync. With the github ease of forking,
| keeping a fork in sync with upstream etc that's a pretty good
| workflow I've found and looks like it'll be possible to stick to it
| in smalltalk talk land - but would like to get notified of the
| inconsistent dependencies so one doesn't have to inspect that by
| hand via debug method #record.

So you can use the following to halt in case of change:

  Metacello new
    configuration: 'A';
    version: #stable;
    onUpgrade: [:ex | self halt ];
    onDowngrade: [:ex | self halt ];
    load.

and arrange for errors ...

I am also providing a `lock` command that allows you to lock down a version of a particular project. An error will be thrown if an attempt is made to load a different version. The `lock` facility is primarily aimed at the use case where you've got a particular version checked out with git and you want to ensure that you are always using the checkout out version.

For your particular use case, you would probably want to `register` your fork of project B so that your fork would always be used for that project ... Given this use case, I would be willing to add a `register` command...

The point of the preview release is to fine tune the API and provide the kind of functionality required by real world use cases.

I am fully prepared to revisit the whole api, if real world use points in different directions ...

----- Original Message -----
| From: "Patrik Sundberg" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, July 25, 2012 8:16:50 AM
| Subject: Re: [Metacello] Can Metacello fail when we have inconsistent dependencies?
|
| On Wednesday, July 25, 2012 3:56:17 PM UTC+1, Dale wrote:
|
| Patrik,
|
| Your questions are feedback are much appreciated.
|
| comments embedded...
|
| ----- Original Message -----
| | To: [hidden email]
| | Sent: Tuesday, July 24, 2012 2:04:51 PM
| | Subject: [Metacello] Can Metacello fail when we have inconsistent
| | dependencies?
| |
| | Hi,
| |
| |
| | I was reading the Metacello PBE2 chapter (excellent!)
|
| Kudos to Stef and Mariano for their work on documenting Metacello!
|
|
|
|
| Indeed, all of the PBE and PBE2 efforts are worth every praise. Makes
| it a lot quicker to get going.
|
|
| | and I see that
| | if we have Project A depending on B and C, and B and C depends on D
| | but not the same version of D, then the latest version that either
| | B
| | or C depends on will be used. Is there a way to make the load
| | fail/raise instead of implicitly picking one version?
|
| Yes, using the scripting api you can get involved in this decision as
| follows:
|
| Metacello new
| configuration: 'A';
| version: #stable;
| onUpgrade: [:ex | ex disallow "default is allow" ];
| onDowngrade: [:ex | ex allow "default is disallow" ];
| load.
|
| The scripting API records the versions of projects that are loaded
| into the image, so when doing the load, the first version B
| encountered will not cause an exception to be raised (an onLoad:
| could be added if there's a use case), but when the second
| (different) version of B is encountered the
| onUpgrade/Downgrade/Conflict exception will be raised and you will
| have an opportunity to "decide".
|
|
|
|
| Cool, that's exactly what I need I think. Does :ex give info about
| both what the already loaded version is as well as the new version
| and who caused them? i.e. is there enough info attached to them to
| work out which projects/packages are causing the conflict.

Yep, the full onUpgrade: looks like the following (the existing and new are available from the exception and are included for convenience:

  onUpgrade: [:ex :existingRegistration :newRegistration | ]


|
|
| |
| |
| | In my current ruby workflow bundler will fail in those instances
| | since it's undefined what the right thing to do is, and then I tend
| | to fork the project's I depend on and make them "compatible",
| | possibly issuing pull requests back upstream and going back to
| | using
| | upstream once they're back in sync. With the github ease of
| | forking,
| | keeping a fork in sync with upstream etc that's a pretty good
| | workflow I've found and looks like it'll be possible to stick to it
| | in smalltalk talk land - but would like to get notified of the
| | inconsistent dependencies so one doesn't have to inspect that by
| | hand via debug method #record.
|
| So you can use the following to halt in case of change:
|
| Metacello new
| configuration: 'A';
| version: #stable;
| onUpgrade: [:ex | self halt ];
| onDowngrade: [:ex | self halt ];
| load.
|
| and arrange for errors ...
|
| I am also providing a `lock` command that allows you to lock down a
| version of a particular project. An error will be thrown if an
| attempt is made to load a different version. The `lock` facility is
| primarily aimed at the use case where you've got a particular
| version checked out with git and you want to ensure that you are
| always using the checkout out version.
|
|
|
|
| I see, sounds like it can be useful.
|
|
| For your particular use case, you would probably want to `register`
| your fork of project B so that your fork would always be used for
| that project ... Given this use case, I would be willing to add a
| `register` command...
|
|
|
|
| Not sure I follow - as I think about it I change the repository when
| using my fork so no need for extra functionality to support that.
| How are you thinking about the register logic?

I haven't implemented the `register` project because I haven't been convinced that it is needed ... the use case for `register` as opposed to `load` is that you may be working in an image where you haven't yet loaded the project, but if you do load the project you want to use a specific one ... The `lock` command allows one to `lock` a project without loading it so the case for `register` is pretty weak ...
 
|
|
|
| The point of the preview release is to fine tune the API and provide
| the kind of functionality required by real world use cases.
|
| I am fully prepared to revisit the whole api, if real world use
| points in different directions ...
|
|
|
|
| So far it looks like a great start and there's just minor tweaks to
| iron out. Also, my way of thinking comes from my
| ruby+bundler+github/gitlab workflow and may not always be sensible
| in a smalltalk setting since my head isn't fully clued up yet. Happy
| to be corrected if some of my comments make no sense to an
| experienced smalltalker.

Yeah, there are certain things that are dictated by image-based development and other things that are dictated by not asking people to change too much at any one time and other things that are dictated by the constraints of the Metacello implementation and other things dictated by my own ignorance and stupicity ...

Sometimes there's a fine line between all of those `dictates`....

I am not familiar with Bundler and the other ruby tools, so I know that there are things to be learned, but there are places where ruby development and smalltalk development diverges ... git is bringing the two closer together in some ways, but Smalltalk will still be aimed at image-based development ...

The preview is a PREVIEW because I need to put a stake in the ground and give folks a chance to get their own hands dirty using the api. So I expect to collect feedback for a bit as people begin using the preview and see what usage patterns emerge ... then make a set of changes based upon the new usage patterns and the feedback ...

Dale

On Wednesday, July 25, 2012 6:01:41 PM UTC+1, Dale wrote:

----- Original Message -----
| To: [hidden email]
| Sent: Wednesday, July 25, 2012 8:16:50 AM
| Subject: Re: [Metacello] Can Metacello fail when we have inconsistent dependencies?
|
| On Wednesday, July 25, 2012 3:56:17 PM UTC+1, Dale wrote:
|
| Patrik,
|
| Your questions are feedback are much appreciated.
|
| comments embedded...
|
| ----- Original Message -----
| | To: [hidden email]
| | Sent: Tuesday, July 24, 2012 2:04:51 PM
| | Subject: [Metacello] Can Metacello fail when we have inconsistent
| | dependencies?
| |
| | Hi,
| |
| |
| | I was reading the Metacello PBE2 chapter (excellent!)
|
| Kudos to Stef and Mariano for their work on documenting Metacello!
|
|
|
|
| Indeed, all of the PBE and PBE2 efforts are worth every praise. Makes
| it a lot quicker to get going.
|
|
| | and I see that
| | if we have Project A depending on B and C, and B and C depends on D
| | but not the same version of D, then the latest version that either
| | B
| | or C depends on will be used. Is there a way to make the load
| | fail/raise instead of implicitly picking one version?
|
| Yes, using the scripting api you can get involved in this decision as
| follows:
|
| Metacello new
| configuration: 'A';
| version: #stable;
| onUpgrade: [:ex | ex disallow "default is allow" ];
| onDowngrade: [:ex | ex allow "default is disallow" ];
| load.
|
| The scripting API records the versions of projects that are loaded
| into the image, so when doing the load, the first version B
| encountered will not cause an exception to be raised (an onLoad:
| could be added if there's a use case), but when the second
| (different) version of B is encountered the
| onUpgrade/Downgrade/Conflict exception will be raised and you will
| have an opportunity to "decide".
|
|
|
|
| Cool, that's exactly what I need I think. Does :ex give info about
| both what the already loaded version is as well as the new version
| and who caused them? i.e. is there enough info attached to them to
| work out which projects/packages are causing the conflict.

Yep, the full onUpgrade: looks like the following (the existing and new are available from the exception and are included for convenience:

  onUpgrade: [:ex :existingRegistration :newRegistration | ]

| |
| | In my current ruby workflow bundler will fail in those instances
| | since it's undefined what the right thing to do is, and then I tend
| | to fork the project's I depend on and make them "compatible",
| | possibly issuing pull requests back upstream and going back to
| | using
| | upstream once they're back in sync. With the github ease of
| | forking,
| | keeping a fork in sync with upstream etc that's a pretty good
| | workflow I've found and looks like it'll be possible to stick to it
| | in smalltalk talk land - but would like to get notified of the
| | inconsistent dependencies so one doesn't have to inspect that by
| | hand via debug method #record.
|
| So you can use the following to halt in case of change:
|
| Metacello new
| configuration: 'A';
| version: #stable;
| onUpgrade: [:ex | self halt ];
| onDowngrade: [:ex | self halt ];
| load.
|
| and arrange for errors ...
|
| I am also providing a `lock` command that allows you to lock down a
| version of a particular project. An error will be thrown if an
| attempt is made to load a different version. The `lock` facility is
| primarily aimed at the use case where you've got a particular
| version checked out with git and you want to ensure that you are
| always using the checkout out version.
|
|
|
|
| I see, sounds like it can be useful.
|
|
| For your particular use case, you would probably want to `register`
| your fork of project B so that your fork would always be used for
| that project ... Given this use case, I would be willing to add a
| `register` command...
|
|
|
|
| Not sure I follow - as I think about it I change the repository when
| using my fork so no need for extra functionality to support that.
| How are you thinking about the register logic?

I haven't implemented the `register` project because I haven't been convinced that it is needed ... the use case for `register` as opposed to `load` is that you may be working in an image where you haven't yet loaded the project, but if you do load the project you want to use a specific one ... The `lock` command allows one to `lock` a project without loading it so the case for `register` is pretty weak ...

| The point of the preview release is to fine tune the API and provide
| the kind of functionality required by real world use cases.
|
| I am fully prepared to revisit the whole api, if real world use
| points in different directions ...
|
|
|
|
| So far it looks like a great start and there's just minor tweaks to
| iron out. Also, my way of thinking comes from my
| ruby+bundler+github/gitlab workflow and may not always be sensible
| in a smalltalk setting since my head isn't fully clued up yet. Happy
| to be corrected if some of my comments make no sense to an
| experienced smalltalker.

Yeah, there are certain things that are dictated by image-based development and other things that are dictated by not asking people to change too much at any one time and other things that are dictated by the constraints of the Metacello implementation and other things dictated by my own ignorance and stupicity ...

Sometimes there's a fine line between all of those `dictates`....

I am not familiar with Bundler and the other ruby tools, so I know that there are things to be learned, but there are places where ruby development and smalltalk development diverges ... git is bringing the two closer together in some ways, but Smalltalk will still be aimed at image-based development ...

The preview is a PREVIEW because I need to put a stake in the ground and give folks a chance to get their own hands dirty using the api. So I expect to collect feedback for a bit as people begin using the preview and see what usage patterns emerge ... then make a set of changes based upon the new usage patterns and the feedback ...