Add SpeckleRhino to Yak

[fraguada]

@pearswj I'd like to revisit adding Speckle to Yak, and I recall, though not very well, that there were some roadblocks to do so. Did this have to do with the fact that we have one rhi for both Rhino and GH functionality? @didimitrie seemed to recall this might have been the issue.

I suppose that one combined installer would trip up things built off of Yak, such as the GH Missing Libraries functionality? Can this install RHIs?

[fraguada]

After discussing Yak behavior with @pearswj, it seems the main issue with these kinds of combined packages (rhp + gha) is that the rhp takes precendence. At the moment, the only functionality that we could benefit from is if a user opens a gh definition with some Speckle component, and they don't have Speckle installed, Yak would detect it and install SpeckleRhino. At the time of writing, Yak looks at the package and grabs the GUID of the rhp, if one is present, otherwise, the gha. This might change in the (near) future, and @pearswj has some ideas. Barring this, and for the short term, we could manually edit the yak package manifest to include the GUID of the gha, and not the rhp.

[pearswj]

Until I change the behaviour – which in hindsight is a bit arbitrary – you can remove the .rhp from the directory temporarily before calling yak spec so that the .gha is used to pre-populate the manifest.yml file.

You'll also need to skip the yak build command and manually zip up the contents of the package as the inspection happens here too. You can push .zip files to the server; No need to rename them to .yak.

A bit of context... The yak spec command is a one-time command designed to help developers to get started with Yak by attempting to create the manifest.yml file from information that is already contained within the .gha/.rhp. Originally I thought I'd sneakily inject the GUID during yak build so that the developer didn't have to even know that it was happening. After all it's only a fallback for when package names don't match the plug-in names, for whatever reason.

[pearswj]

P.S. it's worth checking out the GhCanvasViewport project, in particular the GhCanvasViewportInfo.cs file. Note that the Name matches the name of the package and the Version is taken from the AssemblyInformationalVersion attribute which makes it easy to keep the Grasshopper version in check by updating the assembly version numbers (I used this project as an example of how you could push packages to Yak from AppVeyor (see Automation and CI).