Share Definitions on Github

Hi All,
Is there away to share GH definitions on Github? Say a tool that is developed using GHpython and GH components?

Besides rhe regular “create a repository, add your files, commit and push?” Or are you looking for some kind of integrated way?

Hey Nathan,
I am more interested in the log and changes tracking, ‘share definitions’ as in collaborating with a team member. Can say changes to connections between components be detected in Git? Is there some sort of plug in that can track or mark changes visually between different commits?

I don’t know of such a plug-in. Maybe someone else knows more than I do.

This kind of thing is part of what could be done if GH definitions, including components, could “dump itself” to human readable text files.

Apart from network info like port info and wiring/connections between components, the Script components could dump its ScriptCode (unless “blocked” from export). And conversely, a “new” GH definition could import such text files and instantiate it, and execute it. “Executable models” (from plain text) is a very interesting concept.

This would support roundtrip development of GH definitions, via git. And teamwork of course. And other interesting things as well. This relates to another recent thread :

:no_mouth:

// Rolf

1 Like

Thanks Rolf for sharing!

might be an absolute non sense, but can the network be represented as a noSQL with JSON for each node, and the disconnected nodes would be just ignored?
The Ref is a static id for a GH node, and i is the port# of the node.
so 2 nodes connected together:

Ref-Ouput:{port-output[i]: connection-type}
Ref-Input:{port-Input[i]: Ref-Output}

The output node would only want to know which port is outputting and what kind of stream/connection type

The input node would want to know which output it is receiving from and on which port.

by reading the Database GH can re-establish the tree. if changes are mad the JSON is updated (and thus can compare ‘versions’)…

Anyways, Thanks again!

1 Like

the definition graph network is already human-readable xml, as it turns out. This is what you get when you save a file as a .ghx instead of a .gh file. A .GH file is exactly the same thing, just with the xml converted to binary (making it significantly smaller) If you wanted you could save as .ghx and track on github - While diffs might be more informative, I suspect it would be next to impossible to do a “merge” and have the results be meaningful (but maybe I’m wrong).

A while back at a hackathon I and a few others (Michael Kirschner, Dan Taeyoung, Owen Derby) coded up a system for doing diffs/merges of GH files by representing them in an abstract graph format of our own divising. you can see the source of that experiment here: https://github.com/oderby/VVD

In theory it would be possible to sub out a custom diff/merge engine for certain file extensions in git - though we never got that far.

You might also be interested in another experiment of mine - doing visual diffing with Metahopper like so:

I never wrapped this up into a proper tool but the basic principle relies on the fact that metahopper’s “DocumentInfo” component can read external files as well as the active document - from that you can get all components, params, objects, wires, guids, etc, and do just about whatever you want with that information.

Lastly, another hackathon entry (from the same year!) was @Mostapha’s (along w Chris Mackey, Keith Alfaro, + Matthew Dahlhausen) Hydra tool for sharing Grasshopper scripts. This is of interest because (if I recall) they built a script in grasshopper that handled uploading scripts to github for the purposes of documenting + sharing them. AFAIK there was no piecewise versioning/diffing however.

Hope some of this is helpful, even if the answer to the original question is basically “no, no one has built such a thing” :slight_smile: For what it’s worth, I believe what you’re talking about is technically possible, if not by any means easy!

5 Likes

One approach to achieving this might be to save the script as a series of files within a folder, each file representing a component. The file would define the component (location, input parameters, component id).

I’ve been doing something similar for how to use GIT on an IFC (Industry Foundation Classes) openBIM file. Typically this a building (or infrastructure) project saved to a single text based file (example here https://github.com/jmirtsch/GitIFCPrototype/blob/master/170929%2001%20revit%20beams.ifc ) and instead I’m serializing it to a hierarchial folder structure https://github.com/jmirtsch/GitIFCPrototype/tree/master/111111%20Test%20IfcGit
I wouldn’t expect the folder structure is necessary. This makes the model granular enough to use git on an object by object basis, and diffing and merging should work as already provided by git.

Writing a routine to break the script file into a series of files and converting it back (so that it can be used in Grasshopper) is pretty easy taking advantage of the xml serialization already provided. I started a prototype here:


Presently it’s a component that writes the active script to an adjacent folder.

2 Likes

Interesting. I noticed that there’s a bit “too much” nonsensical info in the xml-file, but if that is stripped out the xml-files seems to be useful in version control.

Examples of tags, or “chunks” to strip out (thumbnails seems to make the xml “dirty” depending on zoom-factor):

<!--
    <chunk name="Thumbnail">
      <items count="1">
        <item name="Thumbnail" type_name="gh_drawing_bitmap" type_code="37">
          <bitmap length="5762">iVBORw0KGgoAAAANSU....{-snip-} ORK5CYII=</bitmap>
        </item>
      </items>
    </chunk>
-->

… and “Projection” too:

<!--
        <chunk name="Projection">
          <items count="2">
            <item name="Target" type_name="gh_drawing_point" type_code="30">
              <X>238</X>
              <Y>52</Y>
            </item>
            <item name="Zoom" type_name="gh_single" type_code="5">1.25</item>
          </items>
        </chunk>
-->

With such uselss info removed, the xml-files can remain identical as long as no essential semantic change is done to the GH definition. I guess there are more tags that can be stripped out, but I noticed these at my first glance after reading your post.

Yes, although not so “human friendly” if one would like to type a GH def in Notepad… :slight_smile:

But anyway, the ghx format seems useful for code generation. Some form of Auto-layout would be gold if having that as a switch after code generation (an xml-property “auto-layout=true” which can be switched off after first manual touch of the GH definition).

A save option (perhaps global option in GH) could be to skip all the zoom-differences and thumbnails and stuff, making the ghx files “cleaner” for version control.

Strict sorting of the xml content would also be important, so that everything that has not changed since last save with be in the same location/order in the xml file.

I use Araxis DIFF tool, and I guess any diff tool suffice to highlight essential changes.

Hooks for pre- and post-processing of saved ghx-files using stored scripts (stored in the global gh settings) would be gold. Then all the above would be easily fixed, and more.

Dreaming.

// Rolf

1 Like

Yes, this could be feasible. Save a stripped version of the .ghx file, sorting by instance guid. Would save the folder approach I was thinking about. Would be a benefit if GH could still directly open the stripped xml file.

perhaps one could just save the ghx-file “as is” but in addition to that strip out desired elements from the ghx-file and save them as separate files. Also this would be a perfect thing for a post-process-script to do.

Edit:

Yes, that would be the most stable sort key. :+1:

// Rolf

See if you can use http://www.food4rhino.com/app/autograph to do what you want.

1 Like

Wow, yes, that seems to be exactly what I was thinking of.

OK, so now I’ll dive into code generation from Enterprise Architect asap.

// Rolf