Editing configurations via tools

If I was writing a configuration tool, how would I do the following:

Given:
glamourProjectSpec := ConfigurationOfVersionner project development projects first.
"spec
        name: 'Glamour for Versionner';
        className: 'ConfigurationOfGlamour';
        versionString: #'stable';
        loads: #('Core' 'Morphic' );
        repository: 'http://www.squeaksource.com/Glamour'."

How would I say: "Add a repository to 'Glamour for Versionner'" or "Load #'development' for 'Glamour for Versionner'"? I would want to offer options like "for this version only" and "globally".

Thanks,
Sean

Sean,

Here are the expressions that add a repository:

(MetacelloToolBox configurationNamed: 'Versionner')
  modifyVersionMethodForVersion: #stable
  versionSpecsDo: [ :attribute :versionSpec |
    attribute == #pharo
      ifTrue: [ | glamour|
        glamour := versionSpec packages detect: [:spec | spec name = 'Glamour for Versionner'].
        glamour repository: 'http://www.example.com/Glamour' ].
    true ];
  commitMethod.

and change versionString to #development:
 
(MetacelloToolBox configurationNamed: 'Versionner')
  modifyVersionMethodForVersion: #stable
  versionSpecsDo: [ :attribute :versionSpec |
    attribute == #pharo
      ifTrue: [ | glamour|
        glamour := versionSpec packages detect: [:spec | spec name = 'Glamour for Versionner'].
        glamour versionString: #development ].
    true ];
  commitMethod.

I haven't done a lot of this kind of programmatic updating and as I read the code, it is obvious that at a minimum I need to provide yet another level of documentation ... If you inspect `versionSpec packages` you see that it is a collection of packge/group/project specs and that there can actually be more than one spec with the same name ... so you have to be aware of which spec you are changing as well as which attribute section you want to edit ... also the versionSpec class has protocol like `packageNamed:` that would seem to be a good choice, but `packageNamed` applies to the processed packages, not the raw specs...

But this does give you an idea of what you can do ... basically #modifyVersionMethodForVersion:versionSpecsDo: reifies a version WITHOUT composing the various attribute sections (#common, #pharo, etc.) allowing you to edit the in the versionSpec however you'd like. The #commitMethod method rewrites the source for the method and compiles it.

Dale
----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 27, 2012 12:23:26 PM
| Subject: [Metacello] Editing configurations via tools
|
| If I was writing a configuration tool, how would I do the following:
|
| Given:
| glamourProjectSpec := ConfigurationOfVersionner project development
| projects
| first.
| "spec
| name: 'Glamour for Versionner';
| className: 'ConfigurationOfGlamour';
| versionString: #'stable';
| loads: #('Core' 'Morphic' );
| repository: 'http://www.squeaksource.com/Glamour'."
|
| How would I say: "Add a repository to 'Glamour for Versionner'" or
| "Load
| #'development' for 'Glamour for Versionner'"? I would want to offer
| options
| like "for this version only" and "globally".
|
| Thanks,
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Editing-configurations-via-tools-tp4636999.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

add a repository:
modifyVersionMethodForVersion: #'development' "No stable version for Pharo 2.0"
...
        glamour repository: 'http://www.example.com/Glamour' ].

I got MNU: MetacelloProjectReferenceSpec>>repository:. When I added one or both of the commented message sends below, there was no error, and the method was rewritten (new version in the versions browser), but the change to the repo was not made

(MetacelloToolBox configurationNamed: 'Versionner')
  modifyVersionMethodForVersion: '1.2-baseline'
  versionSpecsDo: [ :attribute :versionSpec |
    attribute == #common
      ifTrue: [ | glamour|
        glamour := versionSpec packages detect: [:spec | spec name = 'Glamour for Versionner'].
        glamour "referencedSpec projectPackage" repository: 'http://www.example.com/Glamour' ].
    true ];
  commitMethod.

The change versionString: also re-wrote the version, but did not make the change.

Also, the author of the change was TesterBob, who I don't want taking all the credit for my work ;-)

Yeah, that's what I get for sending out untested code, that should work.

1. The MetacelloProjectReferenceSpec class is a delegate for MetacelloProjectSpec and friends. I've only been adding methods when I found that they were needed. `versionString:` is forwarded and `repository:` is not, but could be.

2. The `projectPackage` is an artifact of backwards compatibility. Older versions of specifications exposed the projectPackage and I've maintained the fiction of the `projectPackage` to support those ancient specifications. Using `referencedSpec` should have been enough.

3. I've eliminated the `projectPackage` as a separate object in my most recent work. The protocol remains (and you can get a `projectPackage` but it isn't part of the structure.

4. I'm puzzled that `versionString` didn't stick, sounds like a bug to me. The intent is for that style of interaction to work.

5. testerBob should be diagnostic that this is an area of the code that hasn't been exercised that much:)

For the fringe areas like MetacelloMethodSpec and friends, I've been doing just-in-time development - I try to avoid writing code for anything without an immediate use case, so I've bee patiently waiting for folks to wander into this territory and provide some meaningful use cases...perhaps we've finally gotten there?

The MetacelloProjectSpec hierarchy is significantly changed in my most recent work, so if you are interested in pursuing any bugfixes/development in this area, you should work with the GitHub version.

I am more than willing to share the workload and I am willing to describe what is not clear (can you say class comment fodder?)...

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 28, 2012 4:20:14 PM
| Subject: [Metacello] Re: Editing configurations via tools
|
|
| Dale Henrichs wrote
| >
| > add a repository:
| > modifyVersionMethodForVersion: #'development' "No stable version
| > for Pharo
| > 2.0"
| > ...
| >         glamour repository: 'http://www.example.com/Glamour' ].
| >
|
| I got MNU: MetacelloProjectReferenceSpec>>repository:. When I added
| one or
| both of the commented message sends below, there was no error, and
| the
| method was rewritten (new version in the versions browser), but the
| change
| to the repo was not made
|
| (MetacelloToolBox configurationNamed: 'Versionner')
|   modifyVersionMethodForVersion: '1.2-baseline'
|   versionSpecsDo: [ :attribute :versionSpec |
|     attribute == #common
|       ifTrue: [ | glamour|
|         glamour := versionSpec packages detect: [:spec | spec name =
| 'Glamour for Versionner'].
|         glamour "referencedSpec projectPackage" repository:
| 'http://www.example.com/Glamour' ].
|     true ];
|   commitMethod.
|
| The change versionString: also re-wrote the version, but did not make
| the
| change.
|
| Also, the author of the change was TesterBob, who I don't want taking
| all
| the credit for my work ;-)
|
| --
| View this message in context:
| http://forum.world.st/Editing-configurations-via-tools-tp4636999p4637187.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Right now my number one priority is to get the Metacello scripting API out the door .. my number two priority is to support tools development, but any new tools support will be done in 1.0-beta.32, where I'm doing the scripting api work ...

1.0-beta.32, outside of the scripting api is in perfect working order so it can be used by folks interested in working on tools ... I reserve the right to break 1.0-beta.32 from time to time, so if anyone does start playing with 1.0-beta.32, I'd like to know ... I tend to do development on branches but from time to time I end up doing development on the master branch, if other folks are using 1.0-beta.32 I'll limit my master branch junkets ...

So Sean (or anyone else), if you'd like to work on tools for Metacello and need bugfixes, then I'd like to leverage the collaboration features of GitHub for the work ... if you don't want to dive into the Metacello internals, then forking metacello-work[1] and issuing a pull request with some failing unit tests would kick things off.

The READMEs should provide enough information to get started ... git is probably the biggest hurdle (if you're not familiar with it), but the web does have a lot of resources for learning git and I can give you some pointers to et started ...

Dale

[1] https://github.com/dalehenrich/metacello-work

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: [hidden email]
| Sent: Friday, June 29, 2012 7:34:50 AM
| Subject: Re: [Metacello] Re: Editing configurations via tools
|
| Yeah, that's what I get for sending out untested code, that should
| work.
|
| 1. The MetacelloProjectReferenceSpec class is a delegate for
| MetacelloProjectSpec and friends. I've only been adding methods when
| I found that they were needed. `versionString:` is forwarded and
| `repository:` is not, but could be.
|
| 2. The `projectPackage` is an artifact of backwards compatibility.
| Older versions of specifications exposed the projectPackage and I've
| maintained the fiction of the `projectPackage` to support those
| ancient specifications. Using `referencedSpec` should have been
| enough.
|
| 3. I've eliminated the `projectPackage` as a separate object in my
| most recent work. The protocol remains (and you can get a
| `projectPackage` but it isn't part of the structure.
|
| 4. I'm puzzled that `versionString` didn't stick, sounds like a bug
| to me. The intent is for that style of interaction to work.
|
| 5. testerBob should be diagnostic that this is an area of the code
| that hasn't been exercised that much:)
|
| For the fringe areas like MetacelloMethodSpec and friends, I've been
| doing just-in-time development - I try to avoid writing code for
| anything without an immediate use case, so I've bee patiently
| waiting for folks to wander into this territory and provide some
| meaningful use cases...perhaps we've finally gotten there?
|
| The MetacelloProjectSpec hierarchy is significantly changed in my
| most recent work, so if you are interested in pursuing any
| bugfixes/development in this area, you should work with the GitHub
| version.
|
| I am more than willing to share the workload and I am willing to
| describe what is not clear (can you say class comment fodder?)...
|
| Dale
|
| ----- Original Message -----
| | From: "Sean P. DeNigris" <[hidden email]>
| | To: [hidden email]
| | Sent: Thursday, June 28, 2012 4:20:14 PM
| | Subject: [Metacello] Re: Editing configurations via tools
| |
| |
| | Dale Henrichs wrote
| | >
| | > add a repository:
| | > modifyVersionMethodForVersion: #'development' "No stable version
| | > for Pharo
| | > 2.0"
| | > ...
| | >         glamour repository: 'http://www.example.com/Glamour' ].
| | >
| |
| | I got MNU: MetacelloProjectReferenceSpec>>repository:. When I added
| | one or
| | both of the commented message sends below, there was no error, and
| | the
| | method was rewritten (new version in the versions browser), but the
| | change
| | to the repo was not made
| |
| | (MetacelloToolBox configurationNamed: 'Versionner')
| |   modifyVersionMethodForVersion: '1.2-baseline'
| |   versionSpecsDo: [ :attribute :versionSpec |
| |     attribute == #common
| |       ifTrue: [ | glamour|
| |         glamour := versionSpec packages detect: [:spec | spec name
| |         =
| | 'Glamour for Versionner'].
| |         glamour "referencedSpec projectPackage" repository:
| | 'http://www.example.com/Glamour' ].
| |     true ];
| |   commitMethod.
| |
| | The change versionString: also re-wrote the version, but did not
| | make
| | the
| | change.
| |
| | Also, the author of the change was TesterBob, who I don't want
| | taking
| | all
| | the credit for my work ;-)
| |
| | --
| | View this message in context:
| | http://forum.world.st/Editing-configurations-via-tools-tp4636999p4637187.html
| | Sent from the Metacello mailing list archive at Nabble.com.
| |
|

Dale Henrichs wrote

Right now my number one priority is to get the Metacello scripting API out the door .. my number two priority is to support tools development

Got it.

Dale Henrichs wrote

1.0-beta.32, outside of the scripting api is in perfect working order... if other folks are using 1.0-beta.32 I'll limit my master branch junkets ...

If that's where tool support is/will be, that's where I want to work!

Dale Henrichs wrote

So Sean (or anyone else), if you'd like to work on tools for Metacello and need bugfixes, then I'd like to leverage the collaboration features of GitHub for the work ... if you don't want to dive into the Metacello internals, then forking metacello-work[1] and issuing a pull request with some failing unit tests would kick things off.

I'm comfortable with git and github, but not yet clear on how that connects to Smalltalk... So I write my failing unit test in Pharo and then... [x, y, and z to get it into the file-based world]... or is that in the readme?

Sean

embedded comments...

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Friday, June 29, 2012 7:58:55 AM
| Subject: [Metacello] Re: Editing configurations via tools
|
|
| Dale Henrichs wrote
| >
| > Right now my number one priority is to get the Metacello scripting
| > API out
| > the door .. my number two priority is to support tools development
| >
| Got it.
|
|
| Dale Henrichs wrote
| >
| > 1.0-beta.32, outside of the scripting api is in perfect working
| > order...
| > if other folks are using 1.0-beta.32 I'll limit my master branch
| > junkets
| > ...
| >
| If that's where tool support is/will be, that's where I want to work!
|

Excellent!

|
| Dale Henrichs wrote
| >
| > So Sean (or anyone else), if you'd like to work on tools for
| > Metacello and
| > need bugfixes, then I'd like to leverage the collaboration features
| > of
| > GitHub for the work ... if you don't want to dive into the
| > Metacello
| > internals, then forking metacello-work[1] and issuing a pull
| > request with
| > some failing unit tests would kick things off.
| >
| I'm comfortable with git and github, but not yet clear on how that
| connects
| to Smalltalk... So I write my failing unit test in Pharo and then...
| [x, y,
| and z to get it into the file-based world]... or is that in the
| readme?

The README covers the case of installing and using 1.0-beta.32, but not developing with it ...

1. fork metacello-work
2. clone your fork metacello-work to your machine
3. bootstrap 1.0-beta.32:

"Get the Metacello configuration"
Gofer new
  gemsource: 'metacello';
  package: 'ConfigurationOfMetacello';
  load.

"Bootstrap Metacello 1.0-beta.32, using mcz files"
((Smalltalk at: #ConfigurationOfMetacello) project
  version: '1.0-beta.32') load.

4. Install the latest metacello-work from your clone:

Metacello new
  baseline: 'Metacello';
  repository: 'filetree://', <path to your clone>, '/metacello-work/repository';
  load: 'ALL'.

5. Add unit tests and save package to the filetree repository
6. from command line commit and push to your github repo
7. issue pull request from github

We _could_ work in the same repo, but by using a fork you will have some insulation from the changes that I'm making and if you are doing work in the Metacello core you can feel free to experiment with wide-ranging changes (on a separate branch) without worrying about impacting my work ...

We are both learning about doing collaborative development for Smalltalk and github so we'll have to feel our way a bit ... I am a fan of using topic branchs[1] to isolate work ... but there are other schemes and approaches.

I will welcome contributions of any kind so if you happen to see some particularly ugly code anwywher, create a branch, make some exploratory changes, issue a pull request, and we can start a dialog ...

Dale

[1] https://github.com/dchelimsky/rspec/wiki/Topic-Branches

Here's a link to the workflow used by github[1] and it is a bit simpler than[2] which is good for inspiration...

The github-workflow is actually closer to how I work anyway, so I'm inclined to follow the github-workflow ...

Dale

[1] http://scottchacon.com/2011/08/31/github-flow.html
[2] http://nvie.com/posts/a-successful-git-branching-model/

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: [hidden email]
| Sent: Friday, June 29, 2012 8:18:10 AM
| Subject: Re: [Metacello] Re: Editing configurations via tools
|
| embedded comments...
|
| ----- Original Message -----
| | From: "Sean P. DeNigris" <[hidden email]>
| | To: [hidden email]
| | Sent: Friday, June 29, 2012 7:58:55 AM
| | Subject: [Metacello] Re: Editing configurations via tools
| |
| |
| | Dale Henrichs wrote
| | >
| | > Right now my number one priority is to get the Metacello
| | > scripting
| | > API out
| | > the door .. my number two priority is to support tools
| | > development
| | >
| | Got it.
| |
| |
| | Dale Henrichs wrote
| | >
| | > 1.0-beta.32, outside of the scripting api is in perfect working
| | > order...
| | > if other folks are using 1.0-beta.32 I'll limit my master branch
| | > junkets
| | > ...
| | >
| | If that's where tool support is/will be, that's where I want to
| | work!
| |
|
| Excellent!
|
| |
| | Dale Henrichs wrote
| | >
| | > So Sean (or anyone else), if you'd like to work on tools for
| | > Metacello and
| | > need bugfixes, then I'd like to leverage the collaboration
| | > features
| | > of
| | > GitHub for the work ... if you don't want to dive into the
| | > Metacello
| | > internals, then forking metacello-work[1] and issuing a pull
| | > request with
| | > some failing unit tests would kick things off.
| | >
| | I'm comfortable with git and github, but not yet clear on how that
| | connects
| | to Smalltalk... So I write my failing unit test in Pharo and
| | then...
| | [x, y,
| | and z to get it into the file-based world]... or is that in the
| | readme?
|
| The README covers the case of installing and using 1.0-beta.32, but
| not developing with it ...
|
| 1. fork metacello-work
| 2. clone your fork metacello-work to your machine
| 3. bootstrap 1.0-beta.32:
|
| "Get the Metacello configuration"
| Gofer new
|   gemsource: 'metacello';
|   package: 'ConfigurationOfMetacello';
|   load.
|
| "Bootstrap Metacello 1.0-beta.32, using mcz files"
| ((Smalltalk at: #ConfigurationOfMetacello) project
|   version: '1.0-beta.32') load.
|
| 4. Install the latest metacello-work from your clone:
|
| Metacello new
|   baseline: 'Metacello';
|   repository: 'filetree://', <path to your clone>,
|   '/metacello-work/repository';
|   load: 'ALL'.
|
| 5. Add unit tests and save package to the filetree repository
| 6. from command line commit and push to your github repo
| 7. issue pull request from github
|
| We _could_ work in the same repo, but by using a fork you will have
| some insulation from the changes that I'm making and if you are
| doing work in the Metacello core you can feel free to experiment
| with wide-ranging changes (on a separate branch) without worrying
| about impacting my work ...
|
| We are both learning about doing collaborative development for
| Smalltalk and github so we'll have to feel our way a bit ... I am a
| fan of using topic branchs[1] to isolate work ... but there are
| other schemes and approaches.
|
| I will welcome contributions of any kind so if you happen to see some
| particularly ugly code anwywher, create a branch, make some
| exploratory changes, issue a pull request, and we can start a dialog
| ...
|
| Dale
|
| [1] https://github.com/dchelimsky/rspec/wiki/Topic-Branches
|

Dale Henrichs wrote

...
5. Add unit tests and save package to the filetree repository
6. from command line commit and push to your github repo
7. issue pull request from github

Okay, to get the ball rolling, I added a failing test for the apparent bug we discovered above (that modifying a spec does not stick). Check out the pull request...

Excellent! I'll take a look.

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, June 30, 2012 10:55:15 PM
| Subject: [Metacello] Re: Editing configurations via tools
|
|
| Dale Henrichs wrote
| >
| > ...
| > 5. Add unit tests and save package to the filetree repository
| > 6. from command line commit and push to your github repo
| > 7. issue pull request from github
| >
|
| Okay, to get the ball rolling, I added a failing test for the
| apparent bug
| we discovered above (that modifying a spec does not stick). Check out
| the
| pull request...
|
| --
| View this message in context:
| http://forum.world.st/Editing-configurations-via-tools-tp4636999p4637599.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Based on Dale's work on issue #68, the solution seems to be (untested)...

(MetacelloToolBox configurationNamed: 'Versionner')
  modifyVersionMethodForVersion: '1.2-baseline'
  versionSpecsDo: [ :attribute :versionSpec |
    attribute == #common
      ifTrue: [ | glamour|
        glamour := versionSpec packages specListDetect: [:spec | spec name = 'Glamour for Versionner'].
        glamour referencedSpec repository: 'http://www.example.com/Glamour' ].
    true ];
  commitMethod.

The required changes from the first version in this thread were #specListDetect: and #referencedSpec

With 1.0-beta.32 I plan to add a few methods so that you will be able to write the following:

(MetacelloToolBox configurationNamed: 'Versionner')
  modifyVersionMethodForVersion: '1.2-baseline'
  versionSpecsDo: [ :attribute :versionSpec |
    attribute == #common
      ifTrue: [ | glamour|
        glamour := versionSpec packageList detect: [:spec | spec name =
'Glamour for Versionner'].
        glamour repository: 'http://www.example.com/Glamour'
].
    true ];
  commitMethod.

`packageList detect:` instead of `packages specListDetect:` and no need for `referencedSpec`.

But if you're working wit pre 1.0-beta.32, the above should work...

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Sunday, July 1, 2012 7:31:51 PM
| Subject: [Metacello] Re: Editing configurations via tools
|
| Based on Dale's work on issue #68, the solution seems to be
| (untested)...
|
| (MetacelloToolBox configurationNamed: 'Versionner')
|   modifyVersionMethodForVersion: '1.2-baseline'
|   versionSpecsDo: [ :attribute :versionSpec |
|     attribute == #common
|       ifTrue: [ | glamour|
|         glamour := versionSpec packages specListDetect: [:spec | spec
|         name =
| 'Glamour for Versionner'].
|         glamour referencedSpec repository:
|         'http://www.example.com/Glamour'
| ].
|     true ];
|   commitMethod.
|
| The required changes from the first version in this thread were
| #specListDetect: and #referencedSpec
|
| --
| View this message in context:
| http://forum.world.st/Editing-configurations-via-tools-tp4636999p4637668.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

Here's a link to the workflow used by github[1] and it is a bit simpler than[2] which is good for inspiration...

The github-workflow is actually closer to how I work anyway, so I'm inclined to follow the github-workflow

+1. The Github process sounds like a home run...