search

BHoM / Grasshopper_UI

Tools for Grasshopper
GNU Lesser General Public License v3.0
16 stars 5 forks source link

Consider adding BHoM to Grasshopper Package Manager #661

Closed pawelbaran closed 1 year ago

pawelbaran commented 2 years ago

Description:

As requested by one of the external users, it would be great to start delivering BHoM via the Grasshopper Package Manager. Happy for @FraserGreenroyd to lead this with myself and @al-fisher as support (hands-on and admin, respectively).

@alelom @IsakNaslundBh @adecler FYI

timonielsen commented 2 years ago

Thanks for raising this. This feature is quite essential for using BHoM as the framework for tool development. We wish to be able to distribute tools to our engineers, who may not necessarily have the rights (or will) to go and download and install BHoM. It should install automatically when you open a GH-script that uses BHoM. Thanks for the great work you guys do!

FraserGreenroyd commented 1 year ago

So I have looked into this during this milestone and unfortunately this does not seem possible for the BHoM to be registered with the Grasshopper/Rhino Package Manager.

The Yak packages up all the DLLs necessary for a .gha file, but does not do the same from a .ghlink file. Nor does it allow for packaging up directories outside the same directory as the .gha file. This means we cannot package up the Upgrades folder within %ProgramData%/BHoM/Upgrades. When the package is installed via the Rhino package manager, it installs to a new folder %AppData%\McNeel\Rhinoceros\packages\ (followed by Rhino version e.g. 6.0). So even if we could package up the Upgrades, we would need to change a lot of infrastructure to support relative install paths, which could then break BHoM for other tools, such as Excel, Revit, and Dynamo. Anyone using BHoM for those tools would need to run the MSI installer and would risk having multiple versions of BHoM on their computer.

We could package BHoM for Grasshopper up and exclude the Upgrades, and ensure the Target Invocation Error is handled if the folder doesn't exist (which is currently thrown when installing using this method), but we would then lose one of the key components of BHoM workflow and methodology of being able to upgrade scripts when versions change. People using BHoM for Grasshopper via the package manager would lose all of that richness, and scripts made in 6.0 may not work in 6.1 because of changes made without the versioning available.

As such, I do not deem it feasible for this to be explored further as it will require a lot of work for minimal gain - given the ease of using the MSI installer provided on BHoM.xyz each milestone and the complexity of tools/services the BHoM is offering, the risk of introducing a second way to install BHoM which may conflict with BHoM's own installation process is greater than the gain of making it work, particularly when a suitable solution (MSI installer) exists. If the only option to install BHoM was to compile from source then I would argue for doing it, but as it currently stands, this is a lot of work for minimal gain I'm afraid.