repositories / overrides
Locked
12
12
 
|
Hi,
-- I'm trying to get metacello to load packages from local repositories. I have various directory and filetree repositories. I have a BaselineOfWonkaRuntime class (a subclass of BaselineOf), with the following: baseline: spec <baseline> spec package: 'Sport';
project: 'SeasideDevelopment' copyFrom: 'Seaside30' with: [ spec loads: #('Seaside-Development') ];etc. I would like to load for example Sport, XMLSupport and SoapOpera from my local 3rd party directory Seaside30 from a cloned filetree repository, etc.
I don't want any of the configurations / baselines I depend upon to go over the internet and fetch packages because I want them loaded from my local machine. I would like the dependencies specified of for example the Magritte3 configuration to load its packages and configs from a local repository.
Do I have to specify repository: in each configuration, baseline or package? Or should I be using overrideRepositories: with a list of all the repositories I need? I am out of ideas. I try using the different repository: repositories: overrideRepositories: methods in different places, but battle to get my stuff loaded.
Any ideas welcome. 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,
-- This is where you need my sample project ... override repositories is not going to be used and you shouldn't have to modify any exsiting configurations ... My current sample project does not use a configuration and I think that a configuration (or two) is needed to make the sample complete, but I am bearing down a bit on the internal gemstone work as I am getting close to the deadline ... So if you could hold off until I can get the sample completed, you'll be able to see how I think that the projects can be loaded and then work out any differences between how I think they should be handled and what you are running into in the wild ... Dale From: "Otto Behrens" <[hidden email]> 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. |
|
|
Thanks Dale, will be interesting. In the meantime, I'm trying to get it going with what I've got.
-- On Thu, Nov 21, 2013 at 5:30 PM, Dale K. Henrichs <[hidden email]> wrote:
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,
Just to understand your reply: does repositoryOverrides only work for monticello repositories? Johan On 21 Nov 2013, at 18:04, Otto Behrens <[hidden email]> wrote: > Thanks Dale, will be interesting. In the meantime, I'm trying to get it going with what I've got. > > On Thu, Nov 21, 2013 at 5:30 PM, Dale K. Henrichs <[hidden email]> wrote: > Otto, > > This is where you need my sample project ... override repositories is not going to be used and you shouldn't have to modify any exsiting configurations ... My current sample project does not use a configuration and I think that a configuration (or two) is needed to make the sample complete, but I am bearing down a bit on the internal gemstone work as I am getting close to the deadline ... > > So if you could hold off until I can get the sample completed, you'll be able to see how I think that the projects can be loaded and then work out any differences between how I think they should be handled and what you are running into in the wild ... > > Dale > From: "Otto Behrens" <[hidden email]> > To: [hidden email] > Sent: Thursday, November 21, 2013 6:22:32 AM > Subject: [Metacello] repositories / overrides > > > Hi, > > I'm trying to get metacello to load packages from local repositories. I have various directory and filetree repositories. I have a BaselineOfWonkaRuntime class (a subclass of BaselineOf), with the following: > > baseline: spec > <baseline> > spec > package: 'Sport'; > configuration: 'XMLSupport' with: [ spec loads: #('Core') ]; > configuration: 'SoapOpera' with: [ spec loads: #('Client') ]; > baseline: 'Seaside30' > with: [ > spec > repository: self class localThirdPartySeasideRepository; > loads: #('Base' 'Scriptaculous-Components' 'JQuery-UI') ]; > project: 'SeasideDevelopment' copyFrom: 'Seaside30' with: [ spec loads: #('Seaside-Development') ]; > configuration: 'Magritte3 Base' with: [ spec loads: #('Magritte-Seaside' 'Deprecated') ]; > > etc. > > I would like to load for example Sport, XMLSupport and SoapOpera from my local 3rd party directory Seaside30 from a cloned filetree repository, etc. > > I don't want any of the configurations / baselines I depend upon to go over the internet and fetch packages because I want them loaded from my local machine. > > I would like the dependencies specified of for example the Magritte3 configuration to load its packages and configs from a local repository. > > Do I have to specify repository: in each configuration, baseline or package? Or should I be using overrideRepositories: with a list of all the repositories I need? > > I am out of ideas. I try using the different repository: repositories: overrideRepositories: methods in different places, but battle to get my stuff loaded. > > Any ideas welcome. > > 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. > > > -- > 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. |
|
|
Sorry about that ... repository overrides works, but the technique of using project locks should make it unnecessary to use repository overrides ...
Moving forward I don't think that repository overrides (making a giant repository where all of your packages for all external projects) is the right answer ... Otto ranted about having to manage the repository overrides, so I would like to show him how to "do it the right way" ... I also think that there are other issues that Otto is running into that aren't necessarily related to repository overrides, but given the limited amount of time I have right now, I would rather invest in getting Otto moved to using project locks than solve his current problems doing things the way he is doing it now, then follow that on with moving to using repository locks, where we are likely to cover the same ground doing things a different way ... I assume that the fundamental issue that Otto is having is that we are mixing configurations for GLASS and baselines for GLASS1 and I think that to untangle that particular problem with or without project locks will require changing some configuration/baselines ... if we change the configurations/baselines to support project locking then those edits will be meaningful going forward ... if we make the edits with an eye towards hacking our way around the immediate problems ... those edits won't be compatible with anything going forward and will ahve to managed privately ... and avoiding that mess is precisely why I invented project locks ... Dale ----- Original Message ----- | From: "Johan Brichau" <[hidden email]> | To: [hidden email] | Sent: Thursday, November 21, 2013 11:45:36 AM | Subject: Re: [Metacello] repositories / overrides | | Dale, | | Just to understand your reply: does repositoryOverrides only work for | monticello repositories? | | Johan | | On 21 Nov 2013, at 18:04, Otto Behrens <[hidden email]> wrote: | | > Thanks Dale, will be interesting. In the meantime, I'm trying to | > get it going with what I've got. | > | > On Thu, Nov 21, 2013 at 5:30 PM, Dale K. Henrichs | > <[hidden email]> wrote: | > Otto, | > | > This is where you need my sample project ... override repositories | > is not going to be used and you shouldn't have to modify any | > exsiting configurations ... My current sample project does not | > use a configuration and I think that a configuration (or two) is | > needed to make the sample complete, but I am bearing down a bit on | > the internal gemstone work as I am getting close to the deadline | > ... | > | > So if you could hold off until I can get the sample completed, | > you'll be able to see how I think that the projects can be loaded | > and then work out any differences between how I think they should | > be handled and what you are running into in the wild ... | > | > Dale | > From: "Otto Behrens" <[hidden email]> | > To: [hidden email] | > Sent: Thursday, November 21, 2013 6:22:32 AM | > Subject: [Metacello] repositories / overrides | > | > | > Hi, | > | > I'm trying to get metacello to load packages from local | > repositories. I have various directory and filetree repositories. | > I have a BaselineOfWonkaRuntime class (a subclass of BaselineOf), | > with the following: | > | > baseline: spec | > <baseline> | > spec | > package: 'Sport'; | > configuration: 'XMLSupport' with: [ spec loads: #('Core') ]; | > configuration: 'SoapOpera' with: [ spec loads: #('Client') ]; | > baseline: 'Seaside30' | > with: [ | > spec | > repository: self class localThirdPartySeasideRepository; | > loads: #('Base' 'Scriptaculous-Components' 'JQuery-UI') ]; | > project: 'SeasideDevelopment' copyFrom: 'Seaside30' with: [ spec | > loads: #('Seaside-Development') ]; | > configuration: 'Magritte3 Base' with: [ spec loads: | > #('Magritte-Seaside' 'Deprecated') ]; | > | > etc. | > | > I would like to load for example Sport, XMLSupport and SoapOpera | > from my local 3rd party directory Seaside30 from a cloned filetree | > repository, etc. | > | > I don't want any of the configurations / baselines I depend upon to | > go over the internet and fetch packages because I want them loaded | > from my local machine. | > | > I would like the dependencies specified of for example the | > Magritte3 configuration to load its packages and configs from a | > local repository. | > | > Do I have to specify repository: in each configuration, baseline or | > package? Or should I be using overrideRepositories: with a list of | > all the repositories I need? | > | > I am out of ideas. I try using the different repository: | > repositories: overrideRepositories: methods in different places, | > but battle to get my stuff loaded. | > | > Any ideas welcome. | > | > 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. | > | > | > -- | > 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. | -- 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. |
|
|
In reply to this post by Johan Brichau-3
An alternate answer to your question is that repository overrides are not compatible with git-based packages ... storing packages into a git repository means that you only have one version of the package "visible" at any time ... the repository override technique relies upon the fact that a single repository holds many versions of the same package which reuquires that you use a monticello directory or http repository ...
Dale ----- Original Message ----- | From: "Johan Brichau" <[hidden email]> | To: [hidden email] | Sent: Thursday, November 21, 2013 11:45:36 AM | Subject: Re: [Metacello] repositories / overrides | | Dale, | | Just to understand your reply: does repositoryOverrides only work for | monticello repositories? | | Johan | | On 21 Nov 2013, at 18:04, Otto Behrens <[hidden email]> wrote: | | > Thanks Dale, will be interesting. In the meantime, I'm trying to | > get it going with what I've got. | > | > On Thu, Nov 21, 2013 at 5:30 PM, Dale K. Henrichs | > <[hidden email]> wrote: | > Otto, | > | > This is where you need my sample project ... override repositories | > is not going to be used and you shouldn't have to modify any | > exsiting configurations ... My current sample project does not | > use a configuration and I think that a configuration (or two) is | > needed to make the sample complete, but I am bearing down a bit on | > the internal gemstone work as I am getting close to the deadline | > ... | > | > So if you could hold off until I can get the sample completed, | > you'll be able to see how I think that the projects can be loaded | > and then work out any differences between how I think they should | > be handled and what you are running into in the wild ... | > | > Dale | > From: "Otto Behrens" <[hidden email]> | > To: [hidden email] | > Sent: Thursday, November 21, 2013 6:22:32 AM | > Subject: [Metacello] repositories / overrides | > | > | > Hi, | > | > I'm trying to get metacello to load packages from local | > repositories. I have various directory and filetree repositories. | > I have a BaselineOfWonkaRuntime class (a subclass of BaselineOf), | > with the following: | > | > baseline: spec | > <baseline> | > spec | > package: 'Sport'; | > configuration: 'XMLSupport' with: [ spec loads: #('Core') ]; | > configuration: 'SoapOpera' with: [ spec loads: #('Client') ]; | > baseline: 'Seaside30' | > with: [ | > spec | > repository: self class localThirdPartySeasideRepository; | > loads: #('Base' 'Scriptaculous-Components' 'JQuery-UI') ]; | > project: 'SeasideDevelopment' copyFrom: 'Seaside30' with: [ spec | > loads: #('Seaside-Development') ]; | > configuration: 'Magritte3 Base' with: [ spec loads: | > #('Magritte-Seaside' 'Deprecated') ]; | > | > etc. | > | > I would like to load for example Sport, XMLSupport and SoapOpera | > from my local 3rd party directory Seaside30 from a cloned filetree | > repository, etc. | > | > I don't want any of the configurations / baselines I depend upon to | > go over the internet and fetch packages because I want them loaded | > from my local machine. | > | > I would like the dependencies specified of for example the | > Magritte3 configuration to load its packages and configs from a | > local repository. | > | > Do I have to specify repository: in each configuration, baseline or | > package? Or should I be using overrideRepositories: with a list of | > all the repositories I need? | > | > I am out of ideas. I try using the different repository: | > repositories: overrideRepositories: methods in different places, | > but battle to get my stuff loaded. | > | > Any ideas welcome. | > | > 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. | > | > | > -- | > 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. | -- 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. |
|
|
In reply to this post by otto
Otto,
-- I should be able to find time over the weekend to finish up the sample project ... hopefully it will be in the neighborhood of what you are looking for ... Dale From: "Otto Behrens" <[hidden email]> 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. |
|
|
In reply to this post by otto
Otto,
-- Well, I've got the Example project defined and I've got a real good start documenting my thought on using the `lock` command[1]. Unfortunately, I've run out of time for completing the writeup and won't have too much time in the next couple of days to finish it. I've pretty much tested the scripts in the writeup and I figure that there is enough information for you to get a pretty good idea of what I am thinking. Soo, I'd really appreciate it if you took a critical look at what I am proposing and let me know if it the ideas can be applied to your situation or not. If not, I'd like to make tweaks to the implementation to fit your needs ... I did have to fix some bugs and add a new feature or two[2], so if you want to run the scripts, you should load the issue_215 branch of Metacello to pick up the new features and bugfixes: Metacello new baseline: 'MetacelloPreview'; repository: 'github://dalehenrich/metacello-work:issue_215/repository'; load. BTW, I forked the issue_215 branch before you made your recent changes (another casualty or my lack of time), but that shouldn't affect the functionality. Dale [1] https://github.com/dalehenrich/metacello-work/blob/issue_215/docs/LockCommandReference.md [2] https://github.com/dalehenrich/metacello-work/issues?direction=desc&milestone=17&sort=updated&state=open From: "Otto Behrens" <[hidden email]> 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. |
|
|
Thanks, Dale.
-- > I've pretty much tested the scripts in the writeup and I figure that there is enough information for you to get a pretty good idea of what I am thinking. Soo, I'd really appreciate it if you took a critical look at what I am proposing and let me know if it the ideas can be applied to your situation or not. If not, I'd like to make tweaks to the implementation to fit your needs ... Some ideas: 1. from [1]: "When you lock a baseline-based project: you are telling Metacello to always load the baseline from the given repository and, given the way that baseline-based projects work, to always load the packages referenced by the baseline specification from the given repository." Yes, agree. 2. from [1]: "When you lock a configuration-based project: you are telling Metacello to always use the given version and to always load the configuration from the given repository" This to me is semantically different. In 1, I load whatever version I've got checked out. in 2, I only load a specific version. To me, this does not make sense. I would like the behaviour of 1, always. I don't care what was loaded previously, where it came from or that it is in the registry. I actually want a "Metacello new removeTheRegistry" function. I just want to load what is in the repository that I specify. In the order of dependency specified in the baseline. If I load a new ConfigurationOfGrease or whatever, that defines a new stable that I want to load, I just want it to load that. 3. I'm concerned about the propagation of the lock. If the repository contains various BaselineOf<Project>s, are they also locked? If I lock BaselineOfSeaside30, what happens to ConfigurationOfGrease, currently specified as versionString: '1.0.7.2'. 4. I want to get all my stuff from local repositories. If I load BaselineOfSeaside30, how do I say that Zinc must be loaded from a locally cloned repo? I've now changed our project configurations over to baselines. This is what I've done: baseline: spec <baseline> spec for: #common
do: [ spec baseline: 'Seaside30' with: [ spec repository: self class localThirdPartySeasideRepository;
loads: #('Base' 'Scriptaculous-Components' 'JQuery-UI') ]]; for: #gemstone
do: [ spec baseline: 'Zinc' with: [ spec repository: self class localThirdPartyZincRepository ]] I would like to do this in principle with all the configurations / baselines and I want to be sure that it honors that I've overridden its repository and that it does not hunt for packages / configs elsewhere.
> I did have to fix some bugs and add a new feature or two[2], so if you want to run the scripts, you should load the issue_215 branch of Metacello to pick up the new features and bugfixes:
>> Metacello new > baseline: 'MetacelloPreview'; > repository: 'github://dalehenrich/metacello-work:issue_215/repository'; > load. > > BTW, I forked the issue_215 branch before you made your recent changes (another casualty or my lack of time), but that shouldn't affect the functionality. I see that issue_215 breaks some tests. Don't think it affects the versions we're using. Will try. I've created another pull request. When those tests pass, I'll comment. Not sure if it is all useful.
I got it all loaded eventually with repositoryOverrides:, after unsuccessfully trying locks. 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. |
|
|
In reply to this post by Dale Henrichs-3
Does this all apply to upgrading a seaside.extent0.dbf? Or should I start with extent0.dbf? If I have an existing db, how to I bootstrap Metacello?www.FinWorks.biz
+27 82 809 2375 On Mon, Nov 25, 2013 at 5:43 AM, Dale K. Henrichs <[hidden email]> wrote:
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. |
|
|
In reply to this post by otto
Thanks for the quick response ... your feedback is much appreciated ...
-- From: "Otto Behrens" <[hidden email]>Good point. The original use case for `lock` was targeted at locking the version only[1]. When I applied the `lock` command to the baseline, I had to extend the lock to cover the repository, since baselines don't have an explicit version. When a baseline-based project is locked, you get the packages "for free" thus expanding the potential range of use cases for the `lock` command into the area of managing external projects ... When I wrote the above statement in the writeup, I knew that I was introducing an inconsistency, however, I am not convinced that it is possible/desirable to make the same guarantees for a configuration-based project that are possible for a baseline-based project. [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking Just to be clear, the registry should be giving you the behavior that you are claiming you want. The registry is simply a record of what project versions are loaded in the image (so we can deprecate the currentVersion nonsense). The registry is used to recognize when there is a request to upgrade or downgrade a project and the scripting api provides you with explicit control over what you want to have happen: 1. When you load a specific version of Grease, that fact is recorded in the registry 2. After that point any time if you explicitly load a different version of Grease, the new version is loaded and the new version (upgrade or downgrade) is recorded in the registry. 3. When you load a different project that __references__ Grease, you have the option of specifying `onUpgrade:` and `onDowngrade:` methods where you can decide whether or not (#allow/#disallow) you want the upgrade/downgrade performed. 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 ... 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... As the implementation stands today, locks are not propagated. Each project must be explicitly locked or not locked independently. My intention is to support your use case, so I am willing to work with you to provide tools for doing what you need done ... A `lock` is project specific, but a tool to transitively `lock` all projects reachable from a particular project may be required ... I agree that the best solution to this problem is to convert the *external projects* into baselines. In order to "say that Zinc must be loaded from a locally cloned repo", you would execute the following expression: Metacello baseline: 'Zinc'; repository: <someclass> localThirdPartyZincRepository; lock. After setting the lock, you would use the following pattern for doing loads to ensure that the Zinc locks are `honored`: Metacello ... ... onConflict: [ :ex :existing | existing locked ifTrue: [ ex useIncoming ]. ex pass ]; onLock: [ :ex | ex honor ]; ... With the locks set, no matter where the project reference comes from when loaded, Metacello will make sure that the local Zinc repository is always used with one exception. If you do an explicit load of Zinc, the lock will be automatically broken: Metacello new configuraton: 'Zinc'; version: '1.x'; repostority: 'http:anotherZincREpo'; load. The `lock` for Zinc applies to both baseline-based or configuration-based references anywhere in the loaded project stack ... The tests that failed were not failing consistently across all versions/platforms, so I'm suspicious that network/server availability problems are involved. Nonetheless I will check into the failures tonight. I really think that locks are the going to be the correct answer ... we need to explore the configuration-based issues ... if you are comfortable converting all of your projects to baselines, then perhaps it isn't important to come up with an equivalent solution for configuration-based projects ... Frankly I think that if one is going to "take ownership" of an external project (i.e., copy the configuration and packages to a local repository) the only option that makes sense is to use a git-based repository. Firstly, when it comes time to update to a newer version of the project, you must be able to assess all of the new changes that were made and the only way to really make sense of that is ot use git ... Secondly, if you ever find it necessary to make project bugfixes in your local copy, it doesn't make sense to have to update the configuration with a new project version, and new package versions, when a baseline-based project doesn't require all of that extra overheade ... you just make a new git commit ... Thanks again for your feedback ... I really don't think we are too far apart in what you want and what Metacello provides, but we do have get ourselves on the same page ..... Dale 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. |
|
|
In reply to this post by otto
starting with an extent0.seaside.dbf, here's the whole recommended install sequence as a topaz script:
-- ! ! Upgrade to GLASS 1.0-beta.9.1 ! run ConfigurationOfGLASS project updateProject. GsDeployer deploy: [ (ConfigurationOfGLASS project version: '1.0-beta.9.1') load ]. % commit errorCount ! ! Install most recent Metacello ! run [ Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:issue_215/repository'; load. ] on: Warning do: [:ex | Transcript cr; show: ex description. ex resume]. % commit errorCount From: "Otto Behrens" <[hidden email]> 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. |
|
|
In reply to this post by otto
For an existing db, if you are at GLASS 1.0-beta.9.1 or greater (like GLASS1) then you should only need to do the following:
-- Metacello new baseline: 'MetacelloPreview'; repository: 'github://dalehenrich/metacello-work:issue_215/repository'; load. Dale From: "Otto Behrens" <[hidden email]> 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. |
|
|
In reply to this post by Dale Henrichs-3
> 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. 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. > 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. 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. 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 This simple process was way faster on previous projects than what we currently have. It was also much more reliable because we were sure that we got the methods recompiled and that nothing was missed. You see, the thing is we don't develop on GS. We do a complete deploy of our root package every time we update code. Even with developing on Pharo, we use rebuilt images every day. It may even be easier to load a 'patch' in pharo generated with a git diff for interim updates. Or use git tools in the image. But let's say we still use monticello / metacello. I really don't care about config versions loaded / not. I just need the package dependencies and load order from metacello. And then compare the packages with the versions loaded in the image using Monticello. I really don't get why we need more than this if we really have to use Monticello. > A `lock` is project specific, but a tool to transitively `lock` all projects reachable from a particular project may be required ... Ok, but please not if ConfigurationOf projects are referenced, because locking a version is not the behaviour that I want. > I agree that the best solution to this problem is to convert the *external projects* into baselines. But we will probably have a mix for a while. > In order to "say that Zinc must be loaded from a locally cloned repo", you would execute the following expression: > > Metacello > baseline: 'Zinc'; > repository: <someclass> localThirdPartyZincRepository; > lock. So this means that I can't just load my root BaselineOfWonkaRuntime and expect it to know where to find its stuff. If I have to do this, it means that I should ditch our config that says it depends on Zinc. I can then just as well write a long script that does this for each of the configs / baselines we use and load it explicitly. I thought the idea was that I could just do this: Metacello new baseline: 'MyProject'; repository: <someclass> localThirdPartyZincRepository; load. and in BaselineOfMyProject there should be enough info to know where to get all the code and what versions to use. > I really think that locks are the going to be the correct answer ... we need to explore the configuration-based issues ... if you are comfortable converting all of your projects to baselines, then perhaps it isn't important to come up with an equivalent solution for configuration-based projects ... I've already converted to baselines. If there can be a solution for configuration based issues, then I don't need locks. I need a mode where I just say 'load all the code locally from the local repos'. > Frankly I think that if one is going to "take ownership" of an external project (i.e., copy the configuration and packages to a local repository) the only option that makes sense is to use a git-based repository. Firstly, when it comes time to update to a newer version of the project, you must be able to assess all of the new changes that were made and the only way to really make sense of that is ot use git ... Secondly, if you ever find it necessary to make project bugfixes in your local copy, it doesn't make sense to have to update the configuration with a new project version, and new package versions, when a baseline-based project doesn't require all of that extra overheade ... you just make a new git commit ... I think that using git is great. Some of the community seem to like it, but adoption will possibly not come instantly. -- 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. |
|
|
----- Original Message ----- | From: "Otto Behrens" <[hidden email]> | To: [hidden email] | Sent: Monday, November 25, 2013 10:00:27 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 ... | 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 ... | | > 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? | 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. | | 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 ... | | This simple process was way faster on previous projects than what we | currently have. It was also much more reliable because we were sure | that we got the methods recompiled and that nothing was missed. | | You see, the thing is we don't develop on GS. We do a complete deploy | of our root package every time we update code. Even with developing | on | Pharo, we use rebuilt images every day. It may even be easier to load | a 'patch' in pharo generated with a git diff for interim updates. Or | use git tools in the image. .....I don't see a problem being described here ... is speed of updating the only problem? There are techniques for speeding up migrations by handling the migrations in bulk, but It's not clear to me exactly what your problem is... | | But let's say we still use monticello / metacello. I really don't | care | about config versions loaded / not. I just need the package | dependencies and load order from metacello. And then compare the | packages with the versions loaded in the image using Monticello. I | really don't get why we need more than this if we really have to use | Monticello. This is exactly what a Metacello load does. What is the "more than this" that you are referring to? | | > A `lock` is project specific, but a tool to transitively `lock` all | > projects reachable from a particular project may be required ... | | Ok, but please not if ConfigurationOf projects are referenced, | because | locking a version is not the behaviour that I want. Telling me that something is "not the behavior that I want" provides no useful information ... Let's try to use small, concrete examples of what you do want ... have you run the example code that I created for you? Have you looked at the scripts that I wrote? I think that you should be able to demonstrate your problems by modifying the example projects to illustrate the problems that you are having ... You seem to be ovewhelmed with a bunch of different problems, but to make any sense, we have to start at the beginning and work our way through the various problem areas ... one step at a time .... I know that if we were in the same room we'd have an understanding in a couple of hours, but we do not have that luxury ... so we must make do ... So I propose that we start with the set of projects that I have created and attempt to duplicate ONE of the problems that you are having. So you have to pick ONE of your problems and describe it enough detail that I can understand what the problem might be ... then I will go about tryig to duplicate the problem with the small set of projects and packages ... | | > I agree that the best solution to this problem is to convert the | > *external projects* into baselines. | | But we will probably have a mix for a while. | | > In order to "say that Zinc must be loaded from a locally cloned | > repo", you would execute the following expression: | > | > Metacello | > baseline: 'Zinc'; | > repository: <someclass> localThirdPartyZincRepository; | > lock. | | So this means that I can't just load my root BaselineOfWonkaRuntime | and expect it to know where to find its stuff. The point of the `lock` command is to allow you to change/override the specification of the Zinc project that is referenced from configurations/baslines that you DON'T OWN ... the `lock` command is supposed to save you the effort of changing every external configuration/baseline that references the Zinc project ... The `lock` command is simply a means of specifying an alternate location for project artifacts | If I have to do this, | it means that I should ditch our config that says it depends on Zinc. | I can then just as well write a long script that does this for each | of | the configs / baselines we use and load it explicitly. | Nope ... wrong conclusion... | I thought the idea was that I could just do this: | | Metacello new | baseline: 'MyProject'; | repository: <someclass> localThirdPartyZincRepository; | load. | | and in BaselineOfMyProject there should be enough info to know where | to get all the code and what versions to use. You certainly can do "this", but the problem that `locks` are designed to address comes about when you load an external project that also has a reference to 'MyProject' and that reference specifies a non-local repository location...rerouting the project reference to point to your local repository could have been accomplished by adding some behavior to the onConflict:/onUpgrade:/onDowngrade: messages, but I thought this "re-routing" deserved an explicit specification at the image level rather than forcing you to add the repository mapping logic to every load command ... with all of that said ... I am not convinced that I have "hit the nail on the head" with the `lock` command, but so far I don't have a clear enough picture of your exact use case to know... I have a feeling that you don't quite fully understand the `lock` command either ...or you need to be more specific in your objections:) | | > I really think that locks are the going to be the correct answer | > ... we need to explore the configuration-based issues ... if you | > are comfortable converting all of your projects to baselines, then | > perhaps it isn't important to come up with an equivalent solution | > for configuration-based projects ... | | I've already converted to baselines. If there can be a solution for | configuration based issues, then I don't need locks. I need a mode | where I just say 'load all the code locally from the local repos'. It sounds like you've already done some of the things that I've suggested in the writeup, but it also sounds like you still have some outstanding issues. Why don't you describe the configuration-based issues in detail from your perspective and perhaps we can come up with a solution that works for you... 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. |
|
|
Otto,
Upon reading this mail in the "light of day" I hope I wasn't too harsh ... build and configuration problems are difficult beasts to tame, the only way to tame the beast is to tackle one small problem at a time ... the devil is in the details ... The primary motivation for the Metacello Scripting API is to improve the build process. In order to truly improve the process, I need to have feedback from other folks and that means we have to open wounds and poke around in them ... a painful process ... It takes patience on both sides, but it is also "legal" to do a bit of ranting along the way as it reduces stress in the end ... I am optimistic that we can address the problems that you are having, but in order to do so we have to break the problem down into smaller pieces and build a solution one piece at a time... Dale ----- Original Message ----- | From: "Dale K. Henrichs" <[hidden email]> | To: [hidden email] | Sent: Tuesday, November 26, 2013 1:15:06 AM | Subject: Re: [Metacello] repositories / overrides | | | ----- Original Message ----- | | From: "Otto Behrens" <[hidden email]> | | To: [hidden email] | | Sent: Monday, November 25, 2013 10:00:27 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 ... | | | 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 ... | | | | | > 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? | | | 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. | | | | | 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 ... | | | | | This simple process was way faster on previous projects than what | | we | | currently have. It was also much more reliable because we were sure | | that we got the methods recompiled and that nothing was missed. | | | | You see, the thing is we don't develop on GS. We do a complete | | deploy | | of our root package every time we update code. Even with developing | | on | | Pharo, we use rebuilt images every day. It may even be easier to | | load | | a 'patch' in pharo generated with a git diff for interim updates. | | Or | | use git tools in the image. | | .....I don't see a problem being described here ... is speed of | updating the only problem? There are techniques for speeding up | migrations by handling the migrations in bulk, but It's not clear to | me exactly what your problem is... | | | | | But let's say we still use monticello / metacello. I really don't | | care | | about config versions loaded / not. I just need the package | | dependencies and load order from metacello. And then compare the | | packages with the versions loaded in the image using Monticello. I | | really don't get why we need more than this if we really have to | | use | | Monticello. | | This is exactly what a Metacello load does. What is the "more than | this" that you are referring to? | | | | | > A `lock` is project specific, but a tool to transitively `lock` | | > all | | > projects reachable from a particular project may be required ... | | | | Ok, but please not if ConfigurationOf projects are referenced, | | because | | locking a version is not the behaviour that I want. | | Telling me that something is "not the behavior that I want" provides | no useful information ... Let's try to use small, concrete examples | of what you do want ... have you run the example code that I created | for you? Have you looked at the scripts that I wrote? I think that | you should be able to demonstrate your problems by modifying the | example projects to illustrate the problems that you are having ... | | You seem to be ovewhelmed with a bunch of different problems, but to | make any sense, we have to start at the beginning and work our way | through the various problem areas ... one step at a time .... I know | that if we were in the same room we'd have an understanding in a | couple of hours, but we do not have that luxury ... so we must make | do ... | | So I propose that we start with the set of projects that I have | created and attempt to duplicate ONE of the problems that you are | having. So you have to pick ONE of your problems and describe it | enough detail that I can understand what the problem might be ... | then I will go about tryig to duplicate the problem with the small | set of projects and packages ... | | | | | | > I agree that the best solution to this problem is to convert the | | > *external projects* into baselines. | | | | But we will probably have a mix for a while. | | | | > In order to "say that Zinc must be loaded from a locally cloned | | > repo", you would execute the following expression: | | > | | > Metacello | | > baseline: 'Zinc'; | | > repository: <someclass> localThirdPartyZincRepository; | | > lock. | | | | So this means that I can't just load my root BaselineOfWonkaRuntime | | and expect it to know where to find its stuff. | | The point of the `lock` command is to allow you to change/override | the specification of the Zinc project that is referenced from | configurations/baslines that you DON'T OWN ... the `lock` command is | supposed to save you the effort of changing every external | configuration/baseline that references the Zinc project ... | | The `lock` command is simply a means of specifying an alternate | location for project artifacts | | | | If I have to do this, | | it means that I should ditch our config that says it depends on | | Zinc. | | I can then just as well write a long script that does this for each | | of | | the configs / baselines we use and load it explicitly. | | | | Nope ... wrong conclusion... | | | I thought the idea was that I could just do this: | | | | Metacello new | | baseline: 'MyProject'; | | repository: <someclass> localThirdPartyZincRepository; | | load. | | | | and in BaselineOfMyProject there should be enough info to know | | where | | to get all the code and what versions to use. | | You certainly can do "this", but the problem that `locks` are | designed to address comes about when you load an external project | that also has a reference to 'MyProject' and that reference | specifies a non-local repository location...rerouting the project | reference to point to your local repository could have been | accomplished by adding some behavior to the | onConflict:/onUpgrade:/onDowngrade: messages, but I thought this | "re-routing" deserved an explicit specification at the image level | rather than forcing you to add the repository mapping logic to every | load command ... | | with all of that said ... I am not convinced that I have "hit the | nail on the head" with the `lock` command, but so far I don't have a | clear enough picture of your exact use case to know... I have a | feeling that you don't quite fully understand the `lock` command | either ...or you need to be more specific in your objections:) | | | | | > I really think that locks are the going to be the correct answer | | > ... we need to explore the configuration-based issues ... if you | | > are comfortable converting all of your projects to baselines, | | > then | | > perhaps it isn't important to come up with an equivalent solution | | > for configuration-based projects ... | | | | I've already converted to baselines. If there can be a solution for | | configuration based issues, then I don't need locks. I need a mode | | where I just say 'load all the code locally from the local repos'. | | It sounds like you've already done some of the things that I've | suggested in the writeup, but it also sounds like you still have | some outstanding issues. Why don't you describe the | configuration-based issues in detail from your perspective and | perhaps we can come up with a solution that works for you... | | 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. |
|
|
Ok, don't worry. Yes, certainly we need some patience. I'm also under pressure. Will respond soon. Almost there
On Tuesday, 26 November 2013, Dale K. Henrichs wrote: Otto, -- 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. |
|
|
In reply to this post by Dale Henrichs-3
I meant to say that I want to do: Metacello new
and that is it. I want the BaselineOfWonkaRuntime to do the rest. Inside BaselineOfWonkaRuntime (attached) My entry point is for example: BaselineOfWonkaRuntime
Groups - 'Core' or 'Tests'
fromWonkaRoot - the root of our locally cloned git repo. For this load, the subdirectory structure looks like this: <wonka root>
- 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. |
BaselineOfWonkaRuntime-otto.36.mcz (10K) |
|
PS.
-- The method Metacello | handleWonkaLoadConflict (extension in the BaselineOfWonkaRuntime package) tries to state how I want to control what's loaded. It actually just prefers BaselineOf over ConfigurationOf. 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. |
|
|
In reply to this post by Dale Henrichs-3
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.
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<anything>.
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. |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |