Smalltalk › Frameworks & Tools › Monticello, Metacello ... › Metacello

repositories / overrides

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

otto

Re: repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.

Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

--
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/groups/opt_out.

otto

Re: repositories / overrides

In reply to this post by Dale Henrichs-3

| I am considering this:
| 1. remove all the methods on the classes we work with
| 2. remove classes that are not referenced by the incoming packages
| 3. load all the code
| 4. migrate

I see that we have moved on from the discussion of how to manage external projects into something completely different. I don't think this has anything to do with Metacello.

I would like to see a step by step description of what you are doing and exactly what problems you are experiencing. I don't think you should have to do this, but I clearly don't understand the exact problems that you are facing so I can't judge whether the steps you are threatening to take are necessary or not ...

I was trying to describe a process that Metacello may choose to support or not. In some ways, the combination of Metacello and Monticello does way more than what I need. I understand that. That is OK. But it makes things complex.

I have chosen to use git as a version control system. I want to choose in git what version of what I want to load.

I also need a mechanism to specify dependencies between packages. This is so that I can load stuff in the right order. I think that these are separate concerns.

When we develop, we also use git to merge code between developers. A second version control system (i.e. Monticello + ConfigurationOf classes) on top of the one I use gets in the way. It feels as if the stuff that I am struggling with has to do with that. But this is perhaps too vague. So please ignore this if it does not make sense.

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

Otto,

After taking some time off, I'm ready to get busy with this again:)

I don't understand your whole build process, but I do see the general approach that you are taking ... I can see some limitations to your approach, but I assume that this is working for you or are there still some outstanding problems?

Dale

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Tuesday, November 26, 2013 11:34:20 PM
Subject: Re: [Metacello] repositories / overrides

| > In your case it sounds to me that you want to consistently
| > #disallow any and all upgrades and downgrades to Grease (except
| > when you explicitly load a different version) and this is
| > completely supported by the Metacello Scripting API ...
|
| No, not really. I want to use the same command to load our project.

Not sure what you mean here ...

I meant to say that I want to do:

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

and that is it. I want the BaselineOfWonkaRuntime to do the rest. Inside BaselineOfWonkaRuntime (attached)

My entry point is for example:

BaselineOfWonkaRuntime

loadWonkaRuntimeWithProjectsGroup: 'Core'

fromWonkaRoot: '/home/wonka/development/wonka'

platform: 'GemStone64Bit2.4.4.4-x86_64.Linux'.

Groups - 'Core' or 'Tests'

fromWonkaRoot - the root of our locally cloned git repo. For this load, the subdirectory structure looks like this:

<wonka root>

- 3rdparty

- glass (clone of https://github.com/glassdb/glass)

- zinc (clone of https://github.com/glassdb/zinc)

- Seaside30 (clone of https://github.com/glassdb/Seaside30)

- metacello (clone of https://github.com/finworks/metacello-work)

- shared_mcz (contains ConfigurationOf(GsMonticello|XMLWriter|OSProcess|Gofer|...)<version>.mcz packages. Most recent downloaded from repos. Some modified). Also a number of other mcz's used to bootstrap and those packages not in the cloned repos)

- pharo, GemStone64Bit<version> (contains platform specific mcz packages)
- monticello (contains all our code as a filetree repo)

--
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/groups/opt_out.

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:19:38 AM
Subject: Re: [Metacello] repositories / overrides

| It
| must pick up from disk that there's another version of Grease that I
| want to deploy (i.e. the ConfigurationOfGrease package changed the
| default / core version). And then it must load the new package
| versions.

As far as I can tell you have just described what Metacello does, so I'm not sure what your point is ...

I wanted to say that if I download and a new ConfigurationOfGrease on my machine, my scripts pick it up and load it. I want the new config to be used. If the default / stable version is bumped in it, I want that to be loaded. From disk, on my machine.

| > Soooo, the fact that you want to "Metacello new removeTheRegistry"
| > means that I haven't done a good enough job of communicating this
| > information to you or you have run into bugs ...
| >
| > The Metacello Scripting API is intended to support exactly the
| > behavior you are asking for so we need to work out specifically
| > where it is failing your...
|
| Thanks for the patience, I really battle to understand why I need
| this. I have the code in the DB, on the classes. I don't really care
| about package versions.

In the previous section you claimed that "it must load the new package versions". If you don't care about package versions then how does "it" know which ones are new?

The newly loaded configuration file as explained in the previous point. Read this in the context of locks. If I locked ConfigurationOfGrease, get a new ConfigurationOfGrease package and load it, my understanding is that it will not load the new config & version (if I use my top level loading script). My conclusion is that I should not lock ConfigurationOf.

I will agree, that as things stand right now. You should not lock `ConfigurationOf` ...

However, it is possible to `lock` a #stable version, so the reason for you to not lock ConfigurationOf is not because "it will not load the new config & version", but because locking a ConfigurationOf does not (currently) affect which repository the packages are loaded from (for a ConfigurationOf) and with the current implementation you would still have to use #repositoryOverrides ...

As I think about this, I think we need a locallized version of #repositoryOverrides: ... as #repositoryOverrides stands, the repository override applies to all projects and we'd like a per project repository override... Like the `lock` command you should be able to make a declaration that "in this image, for all Metacllo load operations, the packages for the project should be loaded from that repository"...

Does this make sense?

--
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/groups/opt_out.

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, things can get a bit sticky, but Metacello honors the #atomic load type across project boundaries accumulating packages for one monster load until the end or until a project with a #linear #loadType: is encountered...

Dale

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 7:08:22 AM
Subject: Re: [Metacello] repositories / overrides

| I am considering this:
| 1. remove all the methods on the classes we work with
| 2. remove classes that are not referenced by the incoming packages
| 3. load all the code
| 4. migrate

I see that we have moved on from the discussion of how to manage external projects into something completely different. I don't think this has anything to do with Metacello.

I would like to see a step by step description of what you are doing and exactly what problems you are experiencing. I don't think you should have to do this, but I clearly don't understand the exact problems that you are facing so I can't judge whether the steps you are threatening to take are necessary or not ...

I was trying to describe a process that Metacello may choose to support or not. In some ways, the combination of Metacello and Monticello does way more than what I need. I understand that. That is OK. But it makes things complex.

I have chosen to use git as a version control system. I want to choose in git what version of what I want to load.

I also need a mechanism to specify dependencies between packages. This is so that I can load stuff in the right order. I think that these are separate concerns.

When we develop, we also use git to merge code between developers. A second version control system (i.e. Monticello + ConfigurationOf classes) on top of the one I use gets in the way. It feels as if the stuff that I am struggling with has to do with that. But this is perhaps too vague. So please ignore this if it does not make sense.

The BaselinOf was invented to support development that is based on Git. With the BaselineOf you only specify your package load order and dependencies.

The rest of the cruft in a ConfigurationOf is there to fill the gap that exists between Monticello and Git and is not needed when using Git ... Actually the when using Git it is still convenient to tag certain commits with a version name and ConfigurationOf is still useful for tagging..

Dale

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by Dale Henrichs-3

Otto,

How does something like the following sound to you:

Metacello new
    configuration: 'Grease';
    repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;
    overrideRepository.

".... full set of project to local override repository mappings"

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

You'd be able to get rid of a most if not all of the special class-side load-related methods ... I think that I can arrange to implement the `overrideRepository` command and it would work for both baselines and configurations ...

Dale

From: "Dale K. Henrichs" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:00:44 AM
Subject: Re: [Metacello] repositories / overrides

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, things can get a bit sticky, but Metacello honors the #atomic load type across project boundaries accumulating packages for one monster load until the end or until a project with a #linear #loadType: is encountered...

Dale

otto

Re: repositories / overrides

Hi, I'm on leave so my responses may be slow. Should I then call this overrideRepository for all the sub-projects that I use? So should my script read something like:

Metacello new

configuration: 'Grease';

overrideRepository.

....

Metacello new

configuration: 'Magritte3';

overrideRepository.

.... (And then all the others listed in my baseline)

Metacello new

baseline: 'WonkaRuntime'

load

On Tuesday, 3 December 2013, Dale K. Henrichs wrote:

Otto,

How does something like the following sound to you:

Metacello new
    configuration: 'Grease';
    repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;
    overrideRepository.

".... full set of project to local override repository mappings"

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

You'd be able to get rid of a most if not all of the special class-side load-related methods ... I think that I can arrange to implement the `overrideRepository` command and it would work for both baselines and configurations ...

Dale
From: "Dale K. Henrichs" <<a href="javascript:_e({}, 'cvml', 'dale.henrichs@gemtalksystems.com');" target="_blank">dale.henrichs@...>
To: <a href="javascript:_e({}, 'cvml', 'metacello@googlegroups.com');" target="_blank">metacello@...
Sent: Monday, December 2, 2013 9:00:44 AM
Subject: Re: [Metacello] repositories / overrides

From: "Otto Behrens" <<a href="javascript:_e({}, 'cvml', 'otto@finworks.biz');" target="_blank">otto@...>
To: <a href="javascript:_e({}, 'cvml', 'metacello@googlegroups.com');" target="_blank">metacello@...
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, things can get a bit sticky, but Metacello honors the #atomic load type across project boundaries accumulating packages for one monster load until the end or until a project with a #linear #loadType: is encountered...

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 <a href="javascript:_e({}, 'cvml', 'metacello%2Bunsubscribe@googlegroups.com');" target="_blank">metacello+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.

--
www.FinWorks.biz
+27 82 809 2375

Dale Henrichs-3

Re: repositories / overrides

Turn about's fair play:)

That's basically what I'm thinking, but the trick is that you define a overrideRepository for each project:

Metacello new

configuration: 'Grease';
repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;

overrideRepository.

....

Metacello new

    configuration: 'Magritte3';
    repository: 'filetree:///home/wonka/development/3rdparty/magritte3/repository`;
    overrideRepository.

.... (And then all the others listed in my baseline)

Metacello new

baseline: 'WonkaRuntime'

load

The #repository: message is important because you are associating an override repository with each project ... and the overrideRepo will be used whenever the project is referenced ... Grease has the potential to be referenced from multiple projects ....

Dale

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:42:26 PM
Subject: [Metacello] Re: repositories / overrides

Hi, I'm on leave so my responses may be slow. Should I then call this overrideRepository for all the sub-projects that I use? So should my script read something like:

Metacello new
configuration: 'Grease';

overrideRepository.
....
Metacello new
configuration: 'Magritte3';
overrideRepository.

.... (And then all the others listed in my baseline)
Metacello new
baseline: 'WonkaRuntime'
load

On Tuesday, 3 December 2013, Dale K. Henrichs wrote:

Otto,

How does something like the following sound to you:

Metacello new
    configuration: 'Grease';
    repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;
    overrideRepository.

".... full set of project to local override repository mappings"

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

You'd be able to get rid of a most if not all of the special class-side load-related methods ... I think that I can arrange to implement the `overrideRepository` command and it would work for both baselines and configurations ...

Dale
From: "Dale K. Henrichs" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:00:44 AM
Subject: Re: [Metacello] repositories / overrides

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, things can get a bit sticky, but Metacello honors the #atomic load type across project boundaries accumulating packages for one monster load until the end or until a project with a #linear #loadType: is encountered...

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/groups/opt_out.

--
www.FinWorks.biz
+27 82 809 2375

--
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/groups/opt_out.

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

Otto,

Just checking in to see if you are back and want to pick up where we left off?

Dale

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:42:26 PM
Subject: [Metacello] Re: repositories / overrides

Hi, I'm on leave so my responses may be slow. Should I then call this overrideRepository for all the sub-projects that I use? So should my script read something like:

Metacello new
configuration: 'Grease';

overrideRepository.
....
Metacello new
configuration: 'Magritte3';
overrideRepository.

.... (And then all the others listed in my baseline)
Metacello new
baseline: 'WonkaRuntime'
load

On Tuesday, 3 December 2013, Dale K. Henrichs wrote:

Otto,

How does something like the following sound to you:

Metacello new
    configuration: 'Grease';
    repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;
    overrideRepository.

".... full set of project to local override repository mappings"

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

You'd be able to get rid of a most if not all of the special class-side load-related methods ... I think that I can arrange to implement the `overrideRepository` command and it would work for both baselines and configurations ...

Dale
From: "Dale K. Henrichs" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:00:44 AM
Subject: Re: [Metacello] repositories / overrides

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, things can get a bit sticky, but Metacello honors the #atomic load type across project boundaries accumulating packages for one monster load until the end or until a project with a #linear #loadType: is encountered...

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/groups/opt_out.

--
www.FinWorks.biz
+27 82 809 2375

--
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/groups/opt_out.

otto

Re: repositories / overrides

Not yet. Will let you know

On Thursday, 19 December 2013, Dale K. Henrichs wrote:

Otto,

Just checking in to see if you are back and want to pick up where we left off?

Dale

From: "Otto Behrens" <<a href="javascript:_e({}, 'cvml', 'otto@finworks.biz');" target="_blank">otto@...>
To: <a href="javascript:_e({}, 'cvml', 'metacello@googlegroups.com');" target="_blank">metacello@...
Sent: Monday, December 2, 2013 9:42:26 PM
Subject: [Metacello] Re: repositories / overrides

Hi, I'm on leave so my responses may be slow. Should I then call this overrideRepository for all the sub-projects that I use? So should my script read something like:

Metacello new
configuration: 'Grease';

overrideRepository.
....
Metacello new
configuration: 'Magritte3';
overrideRepository.

.... (And then all the others listed in my baseline)
Metacello new
baseline: 'WonkaRuntime'
load

On Tuesday, 3 December 2013, Dale K. Henrichs wrote:

Otto,

How does something like the following sound to you:

Metacello new
    configuration: 'Grease';
    repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;
    overrideRepository.

".... full set of project to local override repository mappings"

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

You'd be able to get rid of a most if not all of the special class-side load-related methods ... I think that I can arrange to implement the `overrideRepository` command and it would work for both baselines and configurations ...

Dale
From: "Dale K. Henrichs" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:00:44 AM
Subject: Re: [Metacello] repositories / overrides

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, thing

--
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 <a href="javascript:_e({}, 'cvml', 'metacello%2Bunsubscribe@googlegroups.com');" target="_blank">metacello+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.

--
www.FinWorks.biz
+27 82 809 2375

Dale Henrichs-3

Re: repositories / overrides

Cool!

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Thursday, December 19, 2013 1:10:43 PM
Subject: [Metacello] Re: repositories / overrides

Not yet. Will let you know

On Thursday, 19 December 2013, Dale K. Henrichs wrote:
Otto,

Just checking in to see if you are back and want to pick up where we left off?

Dale

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:42:26 PM
Subject: [Metacello] Re: repositories / overrides

Hi, I'm on leave so my responses may be slow. Should I then call this overrideRepository for all the sub-projects that I use? So should my script read something like:

Metacello new
configuration: 'Grease';

overrideRepository.
....
Metacello new
configuration: 'Magritte3';
overrideRepository.

.... (And then all the others listed in my baseline)
Metacello new
baseline: 'WonkaRuntime'
load

On Tuesday, 3 December 2013, Dale K. Henrichs wrote:

Otto,

How does something like the following sound to you:

Metacello new
    configuration: 'Grease';
    repository: 'filetree:///home/wonka/development/3rdparty/grease/repository`;
    overrideRepository.

".... full set of project to local override repository mappings"

Metacello new

baseline: 'WonkaRuntime';

repository: 'filetree:///somewhere';
load

You'd be able to get rid of a most if not all of the special class-side load-related methods ... I think that I can arrange to implement the `overrideRepository` command and it would work for both baselines and configurations ...

Dale
From: "Dale K. Henrichs" <[hidden email]>
To: [hidden email]
Sent: Monday, December 2, 2013 9:00:44 AM
Subject: Re: [Metacello] repositories / overrides

From: "Otto Behrens" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 27, 2013 6:34:51 AM
Subject: Re: [Metacello] repositories / overrides

| I want to make sure that the code I'm loading
| is loaded when I'm done. Even after loading with metacello, we
| currently have to reload all the code again by going through the
| MCWorkingCopy registry and loading the packages using Gofer. This is
| because if there are extensions in a package and the package changes
| underneath it, the overrides are lost.

This sounds like a different problem, I use packages with extensions all of the time and I don't have to reload packages usig Gofer, so there must be something different in the way that you do your load or how you define your packages or ??? but I don't have enough detail here to know where the issue might lie. I need specifics, not generalities.

Sorry, it is not extensions that is the problem. This is the scenario.

Package A defines class Foo.
Package A requires: Package B

load this into GS

Move Foo to Package B (edit in Pharo, save packages).

when loading this in GS, B is required by A, thus loaded first. Because A still defines Foo, the loading of B and then A does not work.

Ah, this is why the #atomic load was invented ... in Monticello if you load each package individually moving a definetion (method or class) from one package to another, Monticello will remove the definition from the image if package A is loaded after package B ... on the other hand if you can arrange to do a multi-package load and load package A and package B in the same load, then Monticello will recognize that the definition was removed and "do the right thing"...

In Metacello you set the #loadType: to #atomic to load all of the packages for a project at the same time ... if package A and package B are in separate projects, thing

--
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/groups/opt_out.

--
www.FinWorks.biz
+27 82 809 2375

--
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/groups/opt_out.

otto

Re: repositories / overrides

In reply to this post by Dale Henrichs-3

> In Metacello you set the #loadType: to #atomic to load all of the packages
> for a project at the same time ... if package A and package B are in
> separate projects, things can get a bit sticky, but Metacello honors the
> #atomic load type across project boundaries accumulating packages for one
> monster load until the end or until a project with a #linear #loadType: is
> encountered...

I've been searching for the right place to do this, but could not find
this on Metacello. MetacelloProject defines it, and it defaults to
atomic (MetacelloProject >> loadType), so I am assuming I'm already
doing an atomic load if I use Metacello. Is this correct? If not, how
would I do this and verify which load type I'm using?

Thanks
Otto

--
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/groups/opt_out.

otto

Re: repositories / overrides

In reply to this post by Dale Henrichs-3

> How does something like the following sound to you:
>
> Metacello new
> configuration: 'Grease';
> repository:
> 'filetree:///home/wonka/development/3rdparty/grease/repository`;
> overrideRepository.
>
> ".... full set of project to local override repository mappings"
>
>
> Metacello new
>
> baseline: 'WonkaRuntime';
>
> repository: 'filetree:///somewhere';
> load

I've been thinking about this one for a while. And it is difficult,
I'm not sure how to do this nicely. Here's an attempt to write my
script along these lines.

| metacello base |
metacello := Metacello new.
base := '/home/wonka/development/wonka/'.
#(#CommandShell #Gofer #GoferProjectLoader #Grease #GsCore #GsFastCGI
#GsMisc #GsMonticello #GsOB #GsSqueakCommon #HelpSystem #Magritte3
#OmniBrowser #OSProcess #ProfStef #RefactoringBrowser #SeasideTesting
#SoapOpera #SPort2 #Swazoo2 #XMLSupport #XMLWriter
#ZincHTTPComponents)
do: [ :configName |
metacello
configuration: configName;
overrideRepository: base , '3rdparty/shared_mcz' ].
#(#Zinc #GLASS1 #Seaside30)
do: [ :baselineName |
metacello
baseline: baselineName;
overrideRepository: 'filetree://' , base , '3rdparty/' ,
baselineName , '/repository' ].
metacello
baseline: 'WonkaRuntime';
repository: 'filetree://' , base , 'monticello';
load

Something like this? More information that what you need, I understand.

What bothers me about this is that we have to keep these lists of
packages up to date in more than one place.

Currently this is working, more or less:

Metacello new
base := '/home/wonka/development/wonka/'.
metacello
baseline: 'WonkaRuntime';
repository: 'filetree://' , base , 'monticello';
repositoryOverrides:
{base , '3rdparty/shared_mcz'},
(#(#Zinc #GLASS1 #Seaside30)
collect: [ :baselineName | 'filetree://' , base , '3rdparty/'
, baselineName , '/repository' ]);
load

What's ugly about this is that there's a list of repository overrides
and this just appears to throw all the packages in one big pot.

> You'd be able to get rid of a most if not all of the special class-side
> load-related methods ... I think that I can arrange to implement the
> `overrideRepository` command and it would work for both baselines and
> configurations ...

I don't see how this would get rid of it because it just changes the
API of the load script. These class side load related methods are our
'scripts' to load specifically our code. I think I still need them; if
so, should I put them elsewhere? Or should they not exist - do the
appear to do things that don't make sense?

Explosion of threads here...

--
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/groups/opt_out.

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Monday, December 30, 2013 1:10:05 AM
| Subject: Re: [Metacello] repositories / overrides
|
| > In Metacello you set the #loadType: to #atomic to load all of the
| > packages
| > for a project at the same time ... if package A and package B are
| > in
| > separate projects, things can get a bit sticky, but Metacello
| > honors the
| > #atomic load type across project boundaries accumulating packages
| > for one
| > monster load until the end or until a project with a #linear
| > #loadType: is
| > encountered...
|
| I've been searching for the right place to do this, but could not
| find
| this on Metacello. MetacelloProject defines it, and it defaults to
| atomic (MetacelloProject >> loadType), so I am assuming I'm already
| doing an atomic load if I use Metacello. Is this correct? If not, how
| would I do this and verify which load type I'm using?

Look at the #project method in your configuration. According to MetacelloConfigTemplate>>project the default #loadType is #linear, so if you haven't explicitly made changes, it's likely that you are using #linear.

The original default was #atomic, but I think I got push back on that (probably indirectly) and I changed the deafult to #linear...
|
| Thanks
| Otto
|
| --
| 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/groups/opt_out.
|

--
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/groups/opt_out.

Dale Henrichs-3

Re: repositories / overrides

In reply to this post by otto

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Monday, December 30, 2013 2:22:15 AM
| Subject: Re: [Metacello] repositories / overrides
|
| > How does something like the following sound to you:
| >
| > Metacello new
| > configuration: 'Grease';
| > repository:
| > 'filetree:///home/wonka/development/3rdparty/grease/repository`;
| > overrideRepository.
| >
| > ".... full set of project to local override repository mappings"
| >
| >
| > Metacello new
| >
| > baseline: 'WonkaRuntime';
| >
| > repository: 'filetree:///somewhere';
| > load
|
| I've been thinking about this one for a while. And it is difficult,
| I'm not sure how to do this nicely. Here's an attempt to write my
| script along these lines.
|
| | metacello base |
| metacello := Metacello new.
| base := '/home/wonka/development/wonka/'.
| #(#CommandShell #Gofer #GoferProjectLoader #Grease #GsCore #GsFastCGI
| #GsMisc #GsMonticello #GsOB #GsSqueakCommon #HelpSystem #Magritte3
| #OmniBrowser #OSProcess #ProfStef #RefactoringBrowser #SeasideTesting
| #SoapOpera #SPort2 #Swazoo2 #XMLSupport #XMLWriter
| #ZincHTTPComponents)
| do: [ :configName |
| metacello
| configuration: configName;
| overrideRepository: base , '3rdparty/shared_mcz' ].
| #(#Zinc #GLASS1 #Seaside30)
| do: [ :baselineName |
| metacello
| baseline: baselineName;
| overrideRepository: 'filetree://' , base , '3rdparty/' ,
| baselineName , '/repository' ].
| metacello
| baseline: 'WonkaRuntime';
| repository: 'filetree://' , base , 'monticello';
| load
|
|
| Something like this? More information that what you need, I
| understand.

Yeah, I think that this is pretty much what I was thinking...

|
| What bothers me about this is that we have to keep these lists of
| packages up to date in more than one place.

I only see one place where they are used, What other places are these lists used?

I've been thinking along the lines of being able to keep a list of Metacello instances (one for each of the projects) that is fully specified for each of the projects ... the instances could be stored somewhere and used as needed, or the isntances could be created on demand.

Ideally you could use the same set of Metacello instances for all of your workflow steps:

BaselineOfWonka configurationProjectSpecs do: [:spec |
"download packages to local disk (see [1] for possible sematics)"
spec fetch ].

BaselineOfWonka projectSpecs do: [:spec |
"download packages to local disk (see [1] for possible sematics)"
spec load ].

If this is the type of thing that you'd like to do, then let's work backwards from here to figure out how we can make that happen...

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScriptingAPI.md#fetching
|
| Currently this is working, more or less:
|
| Metacello new
| base := '/home/wonka/development/wonka/'.
| metacello
| baseline: 'WonkaRuntime';
| repository: 'filetree://' , base , 'monticello';
| repositoryOverrides:
| {base , '3rdparty/shared_mcz'},
| (#(#Zinc #GLASS1 #Seaside30)
| collect: [ :baselineName | 'filetree://' , base , '3rdparty/'
| , baselineName , '/repository' ]);
| load
|
| What's ugly about this is that there's a list of repository overrides
| and this just appears to throw all the packages in one big pot.
|
| > You'd be able to get rid of a most if not all of the special
| > class-side
| > load-related methods ... I think that I can arrange to implement
| > the
| > `overrideRepository` command and it would work for both baselines
| > and
| > configurations ...
|
| I don't see how this would get rid of it because it just changes the
| API of the load script. These class side load related methods are our
| 'scripts' to load specifically our code. I think I still need them;
| if
| so, should I put them elsewhere? Or should they not exist - do the
| appear to do things that don't make sense?
|
| Explosion of threads here...
|
| --
| 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/groups/opt_out.
|

--
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/groups/opt_out.

otto

Re: repositories / overrides

> | #(#CommandShell #Gofer #GoferProjectLoader #Grease #GsCore #GsFastCGI
> | #GsMisc #GsMonticello #GsOB #GsSqueakCommon #HelpSystem #Magritte3
> | #OmniBrowser #OSProcess #ProfStef #RefactoringBrowser #SeasideTesting
> | #SoapOpera #SPort2 #Swazoo2 #XMLSupport #XMLWriter
> | #ZincHTTPComponents)

> | #(#Zinc #GLASS1 #Seaside30)

> | What bothers me about this is that we have to keep these lists of
> | packages up to date in more than one place.
>
> I only see one place where they are used, What other places are these lists used?

My issue is that these lists are embedded in the spec(s) on the
various configurations. If I miss one in this list (that a spec
defines), then I will have trouble finding it.

I still prefer just using repositoryOverrides: because it's less maintenance.

> I've been thinking along the lines of being able to keep a list of Metacello instances (one for each of the projects) that is fully specified for each of the projects ... the instances could be stored somewhere and used as needed, or the isntances could be created on demand.

You've already got an object in the MetacelloProjectRegistration, so I
think that it would be redundant information, which may be
inconsistent and lead to trouble. It may be better to extend the
project spec object to do more.

> Ideally you could use the same set of Metacello instances for all of your workflow steps:
>
> BaselineOfWonka configurationProjectSpecs do: [:spec |
> "download packages to local disk (see [1] for possible sematics)"
> spec fetch ].

Sort of. I want to basically avoid caching, especially the
package-cache because it slows the loading down (If I'm loading stuff
from a repo on the local disk, git or otherwise, it writes a copy of
the package into the package cache. This is redundant as I have the
files on my local disk already.) and I've had situations where there
was inconsistency. This is mainly because we're still manually merging
the stupid version files...

> If this is the type of thing that you'd like to do, then let's work backwards from here to figure out how we can make that happen...

What I would like is to use my original script with my spec (not the
stored / cached spec objects) and ask metacello to copy the mcz
packages into my override repositories. That is because I would like
to update the spec first and then ask it to find what it needs, but
put it in my local repo. (For mcz's and configs).

--
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/groups/opt_out.

Dale Henrichs-3

Re: repositories / overrides

On Mon, Jan 6, 2014 at 11:10 PM, Otto Behrens <[hidden email]> wrote:

> | #(#CommandShell #Gofer #GoferProjectLoader #Grease #GsCore #GsFastCGI
> | #GsMisc #GsMonticello #GsOB #GsSqueakCommon #HelpSystem #Magritte3
> | #OmniBrowser #OSProcess #ProfStef #RefactoringBrowser #SeasideTesting
> | #SoapOpera #SPort2 #Swazoo2 #XMLSupport #XMLWriter
> | #ZincHTTPComponents)

> | #(#Zinc #GLASS1 #Seaside30)

> | What bothers me about this is that we have to keep these lists of
> | packages up to date in more than one place.
>
> I only see one place where they are used, What other places are these lists used?

My issue is that these lists are embedded in the spec(s) on the
various configurations. If I miss one in this list (that a spec
defines), then I will have trouble finding it.

I still prefer just using repositoryOverrides: because it's less maintenance.

> I've been thinking along the lines of being able to keep a list of Metacello instances (one for each of the projects) that is fully specified for each of the projects ... the instances could be stored somewhere and used as needed, or the isntances could be created on demand.

You've already got an object in the MetacelloProjectRegistration, so I
think that it would be redundant information, which may be
inconsistent and lead to trouble. It may be better to extend the
project spec object to do more.

The registry reflects the state of the image and currently is completely independent of the Metacello instances ... resolving inconsistencies (under developer control) is what the the scripting api is all about.

Right now I am not worried about whether or not the project spec is the right object or not ... right now I am interested in finding out what information we need to keep of track to do the job right ...

> Ideally you could use the same set of Metacello instances for all of your workflow steps:
>
> BaselineOfWonka configurationProjectSpecs do: [:spec |
> "download packages to local disk (see [1] for possible sematics)"
> spec fetch ].

Sort of. I want to basically avoid caching, especially the
package-cache because it slows the loading down (If I'm loading stuff
from a repo on the local disk, git or otherwise, it writes a copy of
the package into the package cache. This is redundant as I have the
files on my local disk already.) and I've had situations where there
was inconsistency. This is mainly because we're still manually merging
the stupid version files...

`fetch` is not part of the load operation ... you didn't put this into your workflow, but at some point in time you have to refresh your local disk repositories with new copies of the configuration and any new mcz files that have been added to SmalltalkHub or SS3 or whatever ...

`fetch` would do that job for you and I'm postulating that the "project specs" would contain information like source repository and target repository

The fetch operation would `fetch` the mcz files from the various http repos in the universe and consolidate them in the desired local directory ...

This step was missing from your workflow, but presumably a process needs to be run that polls and downloads fresh versions of the dependent projects at controlled intervals ...

> If this is the type of thing that you'd like to do, then let's work backwards from here to figure out how we can make that happen...

What I would like is to use my original script with my spec (not the
stored / cached spec objects) and ask metacello to copy the mcz
packages into my override repositories.

That is what I imagined the `fetch` command doing ...

That is because I would like
to update the spec first and then ask it to find what it needs, but
put it in my local repo. (For mcz's and configs).

So I postulate that there are three fundamental operations that are done:

1. copy mczs and configurations to the local override repositories

2. pull new commits from remote git repos to local repos

3. load from local (overrides and git) repositories into image

These three do: loops represent those three operations:

BaselineOfWonka configurationProjectSpecs do: [:spec |
"copy mcz packages to my override repositories"
spec copy ].

BaselineOfWonka baselineProjectSpecs do: [:spec |

"pull new git commits to local git repos"
spec pull ].

BaselineOfWonka configurationProjectSpecs,

BaselineOfWonka baselineProjectSpecs do: [:spec |

"load from override repositories into image"
spec load ].

Working backwards from here we need to identify the information that is required to do each of the above steps ...

I think that if we do this we'll be able to have one method/list/script/? where all of the basic information is stored.

I want to solve this set of problems independent of the current scripting API.

My expectation is that we will fold the functionality into the scripting API, but I am willing to make radical changes to the scripting api to get there...

It may make sense to have something like the Metacello configuration (executable specification) for this although for these purposes a method pr two that simple creates instances on demand would be a pretty good soltuion ...

Of course right now the interesting thing to figure out is what information needs to be glommed together for each of the two different project types (mcz vs git) ...

Dale