How to avoid Magritte 3 load Seaside?

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

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

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' );

repository: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' ]

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';

    repository: 'http://smalltalkhub.com/mc/Debris/Quuve/main';

    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? 

--

Mariano
http://marianopeck.wordpress.com

--
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 [hidden email].
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

On Tue, Jul 11, 2017 at 11:25 AM, Dale Henrichs <[hidden email]> 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

Thanks in advance, 

[1] https://github.com/SeasideSt/Seaside/wiki/Contributing

Dale

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

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

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

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' );

repository: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' ]

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';

    repository: 'http://smalltalkhub.com/mc/Debris/Quuve/main';

    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? 

--

Mariano
http://marianopeck.wordpress.com

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

Mariano
http://marianopeck.wordpress.com

--
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 [hidden email].
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

On Tue, Jul 11, 2017 at 11:54 AM, Dale Henrichs <[hidden email]> wrote:

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

On Tue, Jul 11, 2017 at 11:25 AM, Dale Henrichs <[hidden email]> 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

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' );

repository: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' ]

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" ?

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

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

On Tue, Jul 11, 2017 at 2:02 PM, Dale Henrichs <[hidden email]> wrote:

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

On Tue, Jul 11, 2017 at 11:54 AM, Dale Henrichs <[hidden email]> wrote:

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

On Tue, Jul 11, 2017 at 11:25 AM, Dale Henrichs <[hidden email]> 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

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' );

repository: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main' ]

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" ?

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 ...

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?

Yes ... the reference to 'Fielsystem' for GemStone is an error in the configuration of Magritte...

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.