Re: [Pharo-users] Metacello reverse project dependency
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 <wkassens@libello.com> 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 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/
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.) The important is what is fetched from github: Fetched -> BaselineOfBar-PeterUhnak.11 --- github://peteruhnak/ci-bar: *cycle*/repository* [6ac72c0:cycle]* --- github://peteruhnak/ci-bar:*cycle* /repository Fetched -> BaselineOfBar-PeterUhnak.11 --- github://peteruhnak/ci-bar:*deps*/repository *[03d743b:deps]* --- github://peteruhnak/ci-bar:*deps*/repository On Tue, Feb 16, 2016 at 11:17 AM, Werner Kassens <wkassens@libello.com> wrote:
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 On 2/16/16 12: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/
On Mon, Feb 15, 2016 at 11:31 PM, Werner Kassens <wkassens@libello.com <mailto:wkassens@libello.com>> 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:
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
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, 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
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
participants (3)
-
Dale Henrichs -
Peter Uhnák -
Werner Kassens