How to avoid Magritte 3 load Seaside?

10 views
Skip to first unread message

Mariano Martinez Peck

unread,
Jul 11, 2017, 9:24:06 AM7/11/17
to Seaside - general discussion, meta...@googlegroups.com
I cannot find a way to workaround that.

Latest Magritte 3.5.1 ends up using #baseline330:  which calls #baseline310CommonExtDeps: 
That methods does:

project: 'Seaside3'
with: [
"note: we do not want to depend on Zinc, since this is not present in Squeak. Currently no adapter is loaded" 
spec
className: 'ConfigurationOfSeaside3';
versionString: #'stable';
loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome' );

As you can see, it tries to load certain packages from certain Seaside place. And that is bad. Why? Because for example, "Filesystem" is not available for GemStone...so that fails...

I tried this:

"First load seasde and lock it"
Metacello new
   baseline: 'Seaside3';
   repository: 'github://SeasideSt/Seaside:v3.2.2/repository';
   onConflict: [ :ex :loaded :incoming | ex useIncoming ];
   onUpgrade: [ :ex :loaded :incoming | ex useIncoming ];
   "we need this allow for locked grease from gsdevkit filetree shared"
   onLock: [ :ex :loaded :incoming | ex allow ];
   load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email' 'CI');
   lock.


Metacello new
    configuration: 'Quuve';
    version: '1.9';
    get;
    onConflictUseIncoming: #() useLoaded: #('Bootstrap' 'Seaside3');
    onLock: [ :ex :loaded :incoming | ex honor ];
    load: #('Core' 'DPOFX' 'DebrisREST')

And its still trying to load Seaside from the Magritte3 spec...
The only suspect I have is that in magritte it uses ConfigurationOfSeaside3 and shub address while in my code I load BaselineOfSeaside3 from github and so, maybe, Metacello does not even see that as a conflict and hence all my efforts are lost.

Thoughts? 

Dale Henrichs

unread,
Jul 11, 2017, 10:25:09 AM7/11/17
to meta...@googlegroups.com

Mariano,

This looks like a case where the ConfigurationOf for Magritte is broken with respect to GemStone and I think that the configuration for Magritte needs to be fixed ...


There is a Magritte project up on Github[1], but it looks like the latest version is 3.4.2[2] ... If you are changing Magritte that might be the place to do it ...

Dale


[1] https://github.com/GsDevKit/Magritte3

[2] https://github.com/GsDevKit/Magritte3/releases

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mariano Martinez Peck

unread,
Jul 11, 2017, 10:45:43 AM7/11/17
to meta...@googlegroups.com
On Tue, Jul 11, 2017 at 11:25 AM, Dale Henrichs <dale.h...@gemtalksystems.com> wrote:

Mariano,

This looks like a case where the ConfigurationOf for Magritte is broken with respect to GemStone and I think that the configuration for Magritte needs to be fixed ...


There is a Magritte project up on Github[1], but it looks like the latest version is 3.4.2[2] ... If you are changing Magritte that might be the place to do it ...

OK, let's say I do that. 

The current code is this:

spec
        baseline: 'Grease'
          with: [ 
              spec
                loads: #('Core');
                repository: 'github://GsDevKit/Grease:master/repository' ];
        baseline: 'Seaside3'
          with: [ 
              spec
                loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome');
                repository: 'github://GsDevKit/Seaside31:gs_master/repository' ];
        yourself.


As you can see, both, Grease and Seaside3 point to the GsDevKit fork. As far as I know, both, the latest Grease is on Seaside as well as Seaside itself. 

For Seaside, I guess we should be using:

 repository: 'github://SeasideSt/Seaside3:master/repository' 
 
But for Grease, which should I use? GsDevKit fork or Seaside one ???  Joan told me the one from GsDevKit should be fine..but just want to double check with you. 

Finally, let me ask, if I modify BaselineOfMagritte3 to use the above github url for Seaside3, what would happen if I previusly loaded Seaside this way:


Metacello new
   baseline: 'Seaside3';
   repository: 'github://SeasideSt/Seaside:v3.2.2/repository';
   onConflict: [ :ex :loaded :incoming | ex useIncoming ];
   onUpgrade: [ :ex :loaded :incoming | ex useIncoming ];
   "we need this allow for locked grease from gsdevkit filetree shared"
   onLock: [ :ex :loaded :incoming | ex allow ];
   load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email' 'CI');
   lock.

In other words...I want to have CONTROL on which Seaside I load... so I first load 3.2.2 and I lock it. 
But I am not sure if Magritte3's 

  baseline: 'Seaside3'
          with: [ 
              spec
                loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome');
                repository: 'github://SeasideSt/Seaside3:master/repository'  ];

would cause the lock enforce because the repositories are different (see I use 'master'  here as I don't want to hardcode an explicit version). I mean...i don't know if the repository URL is part of the lock key or not...
Here [1] I can read "master: the stable version of Seaside". 


Thanks in advance, 






To unsubscribe from this group and stop receiving emails from it, send an email to metacello+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dale Henrichs

unread,
Jul 11, 2017, 10:54:54 AM7/11/17
to meta...@googlegroups.com



On 7/11/17 7:45 AM, Mariano Martinez Peck wrote:


On Tue, Jul 11, 2017 at 11:25 AM, Dale Henrichs <dale.h...@gemtalksystems.com> wrote:

Mariano,

This looks like a case where the ConfigurationOf for Magritte is broken with respect to GemStone and I think that the configuration for Magritte needs to be fixed ...


There is a Magritte project up on Github[1], but it looks like the latest version is 3.4.2[2] ... If you are changing Magritte that might be the place to do it ...

OK, let's say I do that. 

The current code is this:

spec
        baseline: 'Grease'
          with: [ 
              spec
                loads: #('Core');
                repository: 'github://GsDevKit/Grease:master/repository' ];
        baseline: 'Seaside3'
          with: [ 
              spec
                loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome');
                repository: 'github://GsDevKit/Seaside31:gs_master/repository' ];
        yourself.


As you can see, both, Grease and Seaside3 point to the GsDevKit fork. As far as I know, both, the latest Grease is on Seaside as well as Seaside itself. 

For Seaside, I guess we should be using:

 repository: 'github://SeasideSt/Seaside3:master/repository' 
 
But for Grease, which should I use? GsDevKit fork or Seaside one ???  Joan told me the one from GsDevKit should be fine..but just want to double check with you.
I agree with Johan


Finally, let me ask, if I modify BaselineOfMagritte3 to use the above github url for Seaside3, what would happen if I previusly loaded Seaside this way:


Metacello new
   baseline: 'Seaside3';
   repository: 'github://SeasideSt/Seaside:v3.2.2/repository';
   onConflict: [ :ex :loaded :incoming | ex useIncoming ];
   onUpgrade: [ :ex :loaded :incoming | ex useIncoming ];
   "we need this allow for locked grease from gsdevkit filetree shared"
   onLock: [ :ex :loaded :incoming | ex allow ];
   load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email' 'CI');
   lock.

In other words...I want to have CONTROL on which Seaside I load... so I first load 3.2.2 and I lock it. 
But I am not sure if Magritte3's 

  baseline: 'Seaside3'
          with: [ 
              spec
                loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome');
                repository: 'github://SeasideSt/Seaside3:master/repository'  ];

would cause the lock enforce because the repositories are different (see I use 'master'  here as I don't want to hardcode an explicit version). I mean...i don't know if the repository URL is part of the lock key or not...
Here [1] I can read "master: the stable version of Seaside".
This is the place where the Magritte3 configuration is just plan wrong ... 'Filesystem' should only be loaded for Pharo and not for GemStone so the Magritte baseline (if you are using the github variant) needs to be edited so that the 'Filesystem' load is separated to be pharo specific ...

The lock will make sure that you use 'github://SeasideSt/Seaside:v3.2.2/repository', instead of  'github://SeasideSt/Seaside3:master/repository' but the lock does magically change the 'Filesystem' load...

Dale
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+...@googlegroups.com.

Mariano Martinez Peck

unread,
Jul 11, 2017, 12:20:07 PM7/11/17
to meta...@googlegroups.com
OK. 
 
Finally, let me ask, if I modify BaselineOfMagritte3 to use the above github url for Seaside3, what would happen if I previusly loaded Seaside this way:


Metacello new
   baseline: 'Seaside3';
   repository: 'github://SeasideSt/Seaside:v3.2.2/repository';
   onConflict: [ :ex :loaded :incoming | ex useIncoming ];
   onUpgrade: [ :ex :loaded :incoming | ex useIncoming ];
   "we need this allow for locked grease from gsdevkit filetree shared"
   onLock: [ :ex :loaded :incoming | ex allow ];
   load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email' 'CI');
   lock.

In other words...I want to have CONTROL on which Seaside I load... so I first load 3.2.2 and I lock it. 
But I am not sure if Magritte3's 

  baseline: 'Seaside3'
          with: [ 
              spec
                loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome');
                repository: 'github://SeasideSt/Seaside3:master/repository'  ];

would cause the lock enforce because the repositories are different (see I use 'master'  here as I don't want to hardcode an explicit version). I mean...i don't know if the repository URL is part of the lock key or not...
Here [1] I can read "master: the stable version of Seaside".
This is the place where the Magritte3 configuration is just plan wrong ... 'Filesystem' should only be loaded for Pharo and not for GemStone so the Magritte baseline (if you are using the github variant) needs to be edited so that the 'Filesystem' load is separated to be pharo specific ...

Sure, I understand that and I normally know how to fix that one. What is not completely certain for me is at what level the lock works, I mean, what it uses as the "key" to lock. Read below. 


The lock will make sure that you use 'github://SeasideSt/Seaside:v3.2.2/repository', instead of  'github://SeasideSt/Seaside3:master/repository' but the lock does magically change the 'Filesystem' load...


Ok, I guess you mean "does NOT magically" ... Anyway, I understand the "Filesystem" issue. Put that aside for the moment. My question is,when I locked Seaside3 I locked it by loading a baseline and from github. Would the lock also prevent the shub url. Imagine this project ref:

project: 'Seaside3'
with: [
spec
className: 'ConfigurationOfSeaside3';
versionString: #'stable';
loads: #('Core' 'Javascript' 'RSS' 'Filesystem' 'Welcome' );



Note that it uses ConfigurationOfSeaside3 rather than baseline and it also uses shub repo rather than github.

Would my lock (made on baseline and github) also be in place just because the project is called "Seaside3" ?


ps: can you add me as contributor to Magritte3 on GsDevKit ?



Thanks,

Dale Henrichs

unread,
Jul 11, 2017, 1:02:13 PM7/11/17
to meta...@googlegroups.com
Yes I would expect it to work. The lock command is keyed by "project name" or 'Seaside3' in this case ... the lock command works by substituting the locked project spec for the incoming project spec whenever a project reference is made ... the repository and versionString (if a ConfigurationOf is locked) are the applied without change ... The loads: directive is a bit more complicated, because it is a combination of the locked project spec, the project spec of the currently loaded project and the incoming project spec ...

I notice that in your example above you are supplying all three on* blocks ... this should not be necessary ... at one point in time it was necessary to specify those blocks, but the current version of Metacello honors locks by default.



ps: can you add me as contributor to Magritte3 on GsDevKit ?
You are already a contributor, the developers team should have access to all repositories in GsDevKit ...

Dale

Mariano Martinez Peck

unread,
Jul 11, 2017, 1:24:03 PM7/11/17
to meta...@googlegroups.com
Ok...would that explain why the reference from Magritte to seaside would still try to load "Filesystem" group even when I didn't load that on my locked project? 

 
I notice that in your example above you are supplying all three on* blocks ... this should not be necessary ... at one point in time it was necessary to specify those blocks, but the current version of Metacello honors locks by default.


OK, thanks!
 

ps: can you add me as contributor to Magritte3 on GsDevKit ?
 You are already a contributor, the developers team should have access to all repositories in GsDevKit ...


OK!
 


Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metacello+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dale Henrichs

unread,
Jul 11, 2017, 1:54:41 PM7/11/17
to meta...@googlegroups.com
Yes ... the reference to 'Fielsystem' for GemStone is an error in the configuration of Magritte...

Dale
Reply all
Reply to author
Forward
0 new messages