Posted by Dale Henrichs on Sep 18, 2012; 8:51pm
URL: https://forum.world.st/Smalltalk-X-port-of-Metacello-tp4647981p4648017.html

Jan,

----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 8:44:47 AM
| Subject: Re: [Metacello] Smalltalk/X port of Metacello
|
| On 18/09/12 16:30, Dale Henrichs wrote:
| > Jan,
| >
| > Great news!
| >
| > The vast majority of the tests are associated with the MC packages
| > ... when you take the mcz packages out of the equation there isn't
| > too much to test ... The bulk of the MC tests are doing loads of
| > test packages to test the various features.
| >
|
| If you say so...
|
| I tried to create very simple config like:
|
| version0_0_1: spec
|      <version: '0.0.1'>
|
|      spec for: #common do:[
|          spec package: 'stx:goodies/metacello'.
|      ]
|
|
| and then tried just to inspect
|
| ConfigurationOfMetacello project version: '0.0.1'
|
| and ended up with DNUs. I tried to naively fix them, but more
| appeared.
| I would say this should work without any fancy MC stuff, shouldn't
| it?

Packages are not part of the Core ... which is probably part of why you are getting the DNU's .... the implementation of  MetacelloPackageSpec is very skewed towards Monticello so it is in the MC package ...

The core includes projects and groups so if you pick up my recent work off the master branch you'll be able to create a spec that looks like the following:

baseline0_0_1: spec
     <version: '0.0.1-baseline'>

     spec for: #common do:[
         spec blessing: #baseline.
         spec project: 'Seaside' with: [
           spec
             className: 'ConfigurationOfSeaside';
             versionString: #stable ].
         spec group: 'Core' with: #('Seaside').
     ]

and this should work ... just no packages ...

At ESUG when I said that I didn't like the split that I had ... The package spec is one of the areas that may or may not have some commonality ... I found quite a bit that could be moved from MC to Core for projects, but not being familiar with your needs for packages, I wasn't able to see much commonality ... off the bat ... looking at your implementation of packages may reveal some common code ...

|
| > Last week I did some work to move some of the code that deserves to
| > be in core from MC and I ended up pushing some more tests towards
| > core, but that work was done on the master branch and I noticed
| > that you based your work on the 1.0-beta.31.1.5 branch. You should
| > probably move your port to the master branch as a start.
|
| OK.  I'll update and try it again.

I made quite a few changes moving code from MC to Core and added about 25 tests, so you should have a better experience out of the box using the master branch

|
|
| >
| > We should start considering a generic package test layer ... a
| > bunch of the load tests from MC could be moved into this layer.
| > The details of the test are not specific to Monticello, but you
| > have to have a package loader implemented to run the tests ... I
| > would want to do this work off of the master branch.
| >
| > I will also need to get busy on the new Cypress implementation ...
|
| :-) Yes. We will see how it works in real

I'm looking forward to it!...