As we all know a lot of big companies do not allow software to be installed to their machines themselves, and need to go through software center. On projects, we face this issue that when we distribute dynamo scripts, some package libraries need a reference on their AppData installed in order for the functions in dynamo to work.
So does Speckle.
For me this is an issue as we use baselined packages to distribute our routines throughout the project organization. Using the local send/receive though, Speckle needs to have the object kits installed… this is causing us some issues as it limits us to re-writing the funcionality ourselves in - of course- a worse way.
Can these object kit libraries be included in the package so that we are not dependend on an additional install?
Hey @Dickels112, thanks for sharing this use case!
Would you see the same problem for Grasshopper or any other connector?
I think we can add the package folder as a fallback location in case no kits are found in the appdata folder…
@dimitrie @AlanRynne any thoughts on:
- by default deploying our Kits also in the Dynamo package folder
- adding some logic in Core so that if not kit is found in AppData it’ll start looking in the same location of the Connector dll
If we make this change, we could try to bundle up this issue too: Allow for disabling automatic kit loading in Core · Issue #642 · specklesystems/speckle-sharp · GitHub (they operate in the same space…)
Overall, if this works as a fallback, I’m happy!
Thinking about this some more @Dickels112, I’m afraid there’s another issue, which is account management.
Users who just copy the Speckle for Dynamo pkg folder would not be able to send/receive unless they set up accounts on their machines. This can currently be done in two ways:
- from Speckle Manager
- from the Revit Connector UI (or other connectors using the same UI)
Both do not require admin privileges, and your colleagues might be able to install them themselves, alternatively, we’d be happy to speak with your IT department and help them add Speckle to the Software Center. Let us know if this is an option!
This issue is entirely correct, though the goal we have now is using the local transports, which (understandably) require these kits as well. If we could make use of these functionalities, later on we only will need to exchange this for a client commit should we transfer and make use of this.
ATM we are not able to use speckle within the requirements of the contract, though we are working on implementing the stand-alone server solution.
In this topic I think the issue is relevant to keep in mind, but not applicable to our problem.