Is there a way of specifying alternate repos in Baselines/Configurations
Locked
Is there a way of specifying alternate repos in Baselines/Configurations
 
|
I think this is a fairly common scenario when using a project and its dependencies.
Simple project scenario: - MainProject is cloned locally from github in /opt/git/MainProject - DependentProject is cloned locally from github in /opt/git/DependentProject - MainProject is dependent on DependentProject and refers to its github repository in its BaselineOfMainProject. Loading scenarios: - At the start of each development session, I load my base development image then load the projects I’m working on from their local clones. - Also, in an automated deployment, I want to clone the projects locally then have my image load them from the local disc rather than the network. Loading: If I load my main project with: Metacello new baseline: ‘MainProject’; repository: ‘<a href="filetree:///opt/git/MainProject'" class="">filetree:///opt/git/MainProject'; load It will load the DependProject from github. So, I load DependentProject from my local repo <a href="filetree:///opt/git/DependentProject" class="">filetree:///opt/git/DependentProject using: Metacello new baseline: ‘DependentProject’; repository: ‘<a href="filetree:///opt/git/DependentProject'" class="">filetree:///opt/git/DependentProject'; load I then load MainProject from my local repo <a href="filetree:///opt/git/MainProject" class="">filetree:///opt/git/MainProject using: Metacello new baseline: ‘MainProject’; repository: ‘<a href="filetree:///opt/git/MainProject'" class="">filetree:///opt/git/MainProject'; load Of course, this throws the error: Load Conflict between existing BaselineOfDependentProject [baseline] from <a href="filetree:///opt/git/DependentProject" class="">filetree:///opt/git/DependentProject and BaselineOfDependentProject [baseline] from <a href="github://GitHubUser/DependentProject" class="">github://GitHubUser/DependentProject To get around this, I’m loading DependingProject then locking it with: Metacello new baseline: ‘DependentProject’; repository: ‘<a href="filetree:///opt/git/DependentProject'" class="">filetree:///opt/git/DependentProject'; lock This becomes cumbersome with many dependents and isn’t easy to manage with automated deployments. The pain scales when managing dependents of dependents and third party projects… ideally all of which would be cloned locally. eg. If MainProject depends on Seaside and Seaside depends on Zinc, both of which are cloned locally, BaselineOfMainProject would also need to specify an alternate repo for Zinc. So my question... Is there a way of specifying alternate repos for project dependents and their dependents in BaselineOfMainProject, then selecting which repos will be used at load time, and have them apply to all dependents and their dependents? Right now, I have custom load scripts to circumvent the dependency management Metacello is so good at, doing lots of locking, and wrapping it in GsDeployer deploy: blocks so I don’t get dialogs warning about locks. Pharos loads are even more fiddly. I figure there must be a better way :) How are others managing this? Cheers, Jupiter _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Is there a way of specifying alternate repos in Baselines/Configurations
|
|
Jupiter,
This is one of the issues that I'm addressing with the combo of GsDevKitHome and tODE ... In tODE, you can create "project entries" where you can specify whether or not you want a particular project to be locked or not and what repository to use ... these project entries do not have to represent loaded projects ... when you bring up tODE and use the `project *` family of commands the "project entries" are honored ... In the "waiting for me to write documentation version of GsDevKitHome and tODE)" you specify "project entries" in three locations: default, local and stone. The default is what gets shipped by default in GsDevKitHome ... The local is intended to be a "site-wide" default and can be used to override/extend/prune the default. The stone is created on a stone by stone basis so that you can override the site-wide specification for a particular stone ... Other than some polish and a big dollop of documentation, the GsDevKitHome and tODE code base is functionally complete and I have been using the project entries for exactly the use case you describe for 6 months or so and ... I've gotten sucked into a second round of 3.3 work recently, but if you are interested in taking things for a spin, I can put together some links to the docs that I've already written and maybe fill in some of the blanks ... frankly one of the areas where I felt my documentation was lacking was the area where I was trying to describe how/why project entries are needed, but since you are already painfully aware of the need for project entries, you only need to install the new GsDevKitHome/tODE combo and create the needed project entries ... then convert your load scripts to use the tODE `project command` api and then I think you should be in business ... Dale On 07/06/2015 05:23 PM, Jupiter Jones
via Glass wrote:
I think this is a fairly common scenario when using a project and its dependencies. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Is there a way of specifying alternate repos in Baselines/Configurations
|
|
In reply to this post by GLASS mailing list
Jupiter,
Since we're in diametrically opposed time zones here are links to the draft of the tODE 0.1.0 release notes[1] and the section on project entries[2] ... feedback on the process and documentation are welcome. We can set up a skype session if that would be more efficient ... Dale [1] https://github.com/dalehenrich/tode/blob/dev/docs/releaseNotes/releaseNotes0.1.0.md [2] https://github.com/dalehenrich/tode/blob/dev/docs/releaseNotes/releaseNotes0.1.0.md#project-loading-with-tode On 07/06/2015 05:23 PM, Jupiter Jones
via Glass wrote:
I think this is a fairly common scenario when using a project and its dependencies. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |