Re: Metacello reverse project dependency

Hi Peter,
in your second example, which has a new BaselineOfZar & of bar,
BaselineOfZar-PeterUhnak.9 & BaselineOfBar-PeterUhnak.11 is fetched,
which have the same versionnumber as in the 1st example, are you sure,
that the new baselines of ex2 are loaded?
werner

On 02/16/2016 09:33 AM, Peter Uhnák wrote:
> Unfortunately #includes: doesn't seem to matter and I still get errors.
>
> I tried to somehow summarize my findings with minimal code & results
> here http://peteruhnak.com/metacello/
>

Hi Peter,
ah i see, at least i know now why i dont like git <g>. in your 2nd ex
there is perhaps still a circular dependency, what happens if the
baselines of bar & zar do not rely on baselineoffoo, which isnt used
there anyway ?
werner

On 02/16/2016 11:30 AM, Peter Uhnák wrote:
> Don't look at the metacello version numbers… versions are maintained by
> git ­--- so I can have the same version number refering to different
> code in different branches. (There's no clash because one branch will
> never know about another one.)

Peter,

Very good summary ...

First off, Metacello doesn't support circular project dependencies. Secondly, there is supposed to be a "cucularity detector" in Metacello that avoids going into an infinite loop, but in retrospect, the detector has not been tested with Baselines - I have submitted a bug[1]

Presumably in your second scenario all of the packages load correctly, except that the extensions methods are not loaded ... is that correct?

I think you should be able to address your problem by using the #atomic load type, by adding the following method to each of your baselines:

project
  ^ project
    ifNil: [
      project := super project.
      project loadType: #'atomic'.
      project ].

The default #linear load type loads each package individually. The #atomic load type loads all of the accumulated definitions at one time and missing dependencies like the one you are seeing should be resolved by load time ... The accumulation of definitions crosses project boundaries.

I've submitted a bug to make changing the default load type a bit easier[2] ... sometimes I wish that I made #atomic load the default, but it is hard to change defaults in midstream without causing lots of breakage...

Let me know if this addresses your issue.

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/383
[2] https://github.com/dalehenrich/metacello-work/issues/384

Unfortunately #includes: doesn't seem to matter and I still get errors.

I tried to somehow summarize my findings with minimal code & results here http://peteruhnak.com/metacello/

On Mon, Feb 15, 2016 at 11:31 PM, Werner Kassens <[hidden email]> wrote:

Hi Peter,
have you looked at metacellos #includes: method?
from https://code.google.com/archive/p/metacello/wikis/APIReference.wiki :
"When 'Example-AddOn' is loaded, load 'Example-UI'"
                includes: #('Example-UI' );
werner

On 02/13/2016 11:26 PM, Peter Uhnák wrote:

Hi,

I have the following situation:

I have ProjectMain, and ProjectPlugin, now normally the Plugin depends
on Main, however I would like to load Plugin as part of Main.

The problem is that I can't specify to load Plugin after Main has been
already fully loaded, if I do something like this

BaselineOfMain>>baseline: spec
<baseline>
spec
for: #common
do:
[ spec
baseline: 'Plugin'
with: [ spec
repository: '...';
loads: #('default' OR 'plugin') ].
spec
package: 'Main' with: [ spec requires: #(more stuff) ];
spec group: 'default' with: #('Main').
specgroup: 'complete' with: #('default' 'Plugin') ]

The BaselineOfPlugin has two groups… "default", which loads also "Main",
and "plugin", which doesn't.

Now the problem is that there is no guaranteed way that Plugin will load
after Main (in fact the should happen). If I load the plugin's #default,
then Metacello ends up in an endless loop for some reason, and if I load
#plugin, then it will load it before the Main which will break it
(because Plugin has dependencies on main).

So my question is:
is it possible to reverse it somehow?
Maybe add at the end `specpostLoadDoIt: #postLoadPlugins`, and then in
that method manually load the plugins with Metacello/Gofer? Or is there
a better way?

Thanks,
Peter

Hi Dale,
since you are reading this forum, may i ask you another qestion here
(btw i asked for access to the metacello forum, i dont know, a year ago
or so but didnt get it)? assumed i have a project (with a config) in a
baseline and several packages in that baseline with dependencies on
specific packages of this project. with that #import: method i could
model this dependencies of course, but i guess #import: is only for
git-baselines, or? if this is correct, is there a possibility to model
these dependencies without making a special project for each of these?
or simpler: project consists of packA & packB, my baseline consists of
project (only via its config) and packC & packD, packC depends on packB,
and packD depends on packA. now i want to load eg packD via my baseline
and this should of course load also packA but not packB. (and no git
involved.)
werner

Sorry about that Werner ... I had been getting my mail forwarded from
the Metacello Group to my work email and apparently a year ago, the mail
(silently) stopped being forwarded, so I was none the wiser until you
mentioned it just now ... and I've approved your membership request
along with several others that had queued up ...

It would be easier for me to understand what you are proposing with an
actual example of spec - the way that you'd like to see it...

Also I don't quite understand what you mean by "no git involved" are you
using a filetree:// repo or an mcz repository or what ... Metacello
knows about github:// repos but as far as Metacello is concerned a "git
repo" is just a filetree repo ...

Dale


On 2/16/16 10:04 AM, Werner Kassens wrote:

Werener,

Here's an example of the use of #import:provides: from my tests that
might be in the area you are interested in:

  spec
     for: #'common'
     do: [
       spec description: self name , '>>configuration092Issue63:'.
       spec
         baseline: 'External'
           with: [
               spec
                 repository:
                   'github://dalehenrich/external:' ,
MetacelloScriptingResource externalCustomSHA
                     , '/repository' ];
         package: 'GoferBar'
           with: [
               spec
                 file: 'GoferBar-lr.1';
                 requires: 'External-Core';
                 repository:
'dictionary://Metacello_Gofer_Test_Repository' ];
         package: 'GoferFoo'
           with: [
               spec
                 file: 'GoferFoo-lr.2';
                 requires: 'External-Tests';
                 repository:
'dictionary://Metacello_Gofer_Test_Repository' ];
         import: 'External' provides: #('External-Core' 'External-Tests') ]

the feature was create for use with baseline project refs and my test
cases all involve baselines, but I don't think that the feature is
necessarily restricted to use with baseline projects ... BTW, the
#import:provides: was created so that you could import specific
packages/groups from more than one baseline and to also avoid importing
group names from a baseline that may already exist in the project ...

Dale

On 2/16/16 10:04 AM, Werner Kassens wrote:

Hi Dale,
thanks for aprouving the membership request.
i was talking about a mcz repository. lets say i have myconfig (mcz)
with a baseline, a stable and a development version. the baseline of
that config could eg look like this:

spec project: 'SciSTSpecial' with: [
        spec className: 'ConfigurationOfSciSmalltalk';
                versionString: #stable;
                repository: '
http://smalltalkhub.com/mc/SergeStinckwich/SciSmalltalk/main/';
                loads: #('Math-DHB-Numerical' 'Math-DHB-wk'].
        spec package: 'packA'with: [spec requires: #('SciSTSpecial')].
        spec package: 'packB' with: [spec requires: #('SciSTSpecial')].
        spec group: 'default' with: #('packA' 'packB').

but that is only an approximation what i want. instead i would like to
do something like this:

spec project: 'SciST' with: [
        spec className: 'ConfigurationOfSciSmalltalk';
                versionString: #stable;
                repository: '
http://smalltalkhub.com/mc/SergeStinckwich/SciSmalltalk/main/'];
        import:#('Math-DHB-Numerical' 'Math-DHB-wk')."but i guess i cant use
that here?"
        spec package: 'packA'with: [spec requires: #('Math-DHB-Numerical')].
        spec package: 'packB' with: [spec requires: #('Math-DHB-wk')].
        spec group: 'default' with: #('packA' 'packB').
...
and in this case 'packB' would not only first load 'Math-DHB-wk' but
also 'Math-DHB-Numerical' since the baseline of
'ConfigurationOfSciSmalltalk' says that 'Math-DHB-wk' depends on
'Math-DHB-Numerical'. and all this should not only work on the stable
version of 'ConfigurationOfSciSmalltalk' (as defined here in the
baseline), which could eg be overscribed in the development version of
myconfiguration and then eg a different 'Math-DHB-wk' version would be
loaded than in the stable version.

hence i guess my question is essentially, can i always use #import: in a
normal config? the docu is not too informative here. a propos i find the
docu in the old google wiki occasionaly really helpful, i'd appreciate
it if the APIReference & the CustomProjectAttributes (the APIReference
is very often useful) would be saved to the git docu.
werner