-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(V3) it seems a bit redundant to have the specify the projectsHome when loading a spec from an already cloned project #923
Comments
so, if I load a project spec from within a repo, and it refers to a bunch of other projects that also need to be loaded, will they load in the same "parent" directory |
there's also #projectDirectory in the registry. not sure where in the "projects home" hierarchy that should fit, unless that becomes the new ROWAN_PROJECTS_HOME. Maybe, if you're loading a spec from a remote server (ie. github://) then either the user specifies where the "projects home" is, or it uses #projectDirectory from the registry. If you load a project spec from the local disk (ie. file://) then presumably you've cloned it in the place where you want it, so that would use the repo's parent as "projects home" |
@JupiterJones ..oh,oh .... if we're not careful we'll end up recreating tODE using .stone scripts, _stones scripts and bash can become the tODE command line interface ... vi/eMacs can edit individual methods ... hmmm 😎 |
On a more practical note ... we can write a variant of installProject.stone that does the work of figuring out whether the load spec path and the load spec itself is enough to resolve to the project home ... Next Rowan has the notion of a load spec set that you get by sending ??? (I'm replying on my phone so I can't look up the message🙂)... anyway ... after sending the message you get the list of required projects specs from the project structure and at that point the .stone script can set the project home for each spec by looking up the project in project set ... hmmm specified on the command line .... I'll have to get down to my computer to look up the details ... on a side note that's the cool thing about a .stone script you can work out the basic details in the script and then push the code out into Rowan or _stones or wherever after you've got the details worked out ... |
Okay ... The project dalehenrich/RowanSample9V3 contains 80 some branches that are examples of a variety of different projects, including multiple project sampless ... The README on the master branch is an index to the projects. In this example I'm using the raw url for the the spec_001 spec/branch to get my hands on the load spec:
spec_0001 has no required projects, so the next step is to resolve the load spec which uses projectsHome to determine where the project should be cloned:
After executing the above, the samples directory will contain the clone project on the spec_0001 branch:
If we choose a load spec that has required projects (spec_0067) and do the #resolve:
We'll get:
And the loadSpecSet contains the load specs for all of the required projects:
And now we have the opportunity to set the projectsHome for each of the specs or make any other changes to all of the specs PRIOR to doing the load and clone ... by default the required projects are cloned in the projectsHome of the original load spec ... We do have to clone the original project to get the list of required projects ... |
But not if the spec is loaded from a file:// url, AND the spec's parent directory contains a project.ston spec? |
Discussing this with @JupiterJones, it seems that it should be possible to infer/calculate the root directory of a project (and by extension the projects homes directory) from the location of project spec file.
Given this load spec and the original path used to read the spec (see the #projectSpecFile):
I think that at worst we can look at the path and if we find a 'rowan' in the path to the load spec... AND we find a project spec relative to that
rowan
:then we can guess as to a probably projects home AND then if we can find a matching project spec and load spec using that guess we are ready to rumba ...
Now we just need to define the error conditions ...
If ROWAN_PROJECTS_HOME is not set ... we're in like flint ... if a projects home is supplied, then we don't bother checking ...
If ROWAN_PROJECTS_HOME is set? I think we have to unconditionally honor it ...
The text was updated successfully, but these errors were encountered: