Package Manager important things missing?

Rhino Developer Yak
1

Hi,

I like that the Package Manager lists some plugins. But why only those few and it doesn’t show others that are listed under plugins/options locally? Why are only those few on the list?
Also and I think this is an important feature that is missing is that when you use it, it doesn’t allow you choose your install location on your computer so where is the plugin located? One can find that in information in options/plugins but then the plugin is already preinstalled on c drive. Ouch I don’t have the room.

In this case take Dales polyhedra plugin I really like that I could download it and install it this easily without having to do anything yet a few things I find troubling:
Is there not the need for security how can we pre-scan the plugin before install?
How can we find where the plugin is located easily maybe there should be an options tab in the PM?
Why can’t we choose an installation path?
Shouldn’t it be combined or folded into the Plugin manager?
Maybe I missing what this is all about and it’s not primarily for plugin control?

And it just occurred to me is this going to be like a Native instruments all plugins listed online when you log in or like composer cloud where your plugins are stored on the web until you download them or pay for them?
RM

2

I moved the Grasshopper\Library folder and replaced it with a “symlink” (that can be done with the Rhino\Plugin folder as well). So the entire \AppData\Roaming\Grasshopper chunk is physically located on my D drive while the symlink makes it look like it’s still in its original location.

I use ShellLinkExtensions (Windows 10) to manage my symlinks.
The application installs so you can Right Click in File Explorer. Just “Pick” the folder you want to move and “Drop” it onto another disk, or wherever)

Using symlink you can free you C-drive from lots of junk by moving folders elsewhere.

// Rolf

3

Hey @3dsynergy, I’ve tried to answer all of your questions here. Let me know if you have any more!

The separation between the package manager and the plug-in manager is intentional. The package manager is just one way to install plug-ins for Rhino and packages can also contain Grasshopper plug-ins and/or Grasshopper user-objects. As time goes on we’ll add more things that can be distributed via packages too.

The relationship with the plug-in manager has been raised in the past. Do you think it would be useful to highlight plug-ins that have been installed by the package manager?

I’ve logged the request for a custom install directory (RH-60023) and I’ll keep an eye out for other similar requests. For now, I think Rolf’s suggestion to use symlinks is a good one. I tested this by opening cmd.exe as an Administrator and running this command…

mklink /d C:\Users\will\AppData\Roaming\McNeel\Rhinoceros\packages\7.0 D:\packages

Make sure to delete the 7.0 directory first. Everything seems to work as expected and packages are now stored on my D:\ drive.

For a bit of background information, the intention with the package manager was to move away from a system where, particularly for Grasshopper plug-ins, you had to physically move files into specific directories in order to “install” them. In my experience of answering Rhino Installer Engine questions the main reason that users want to find the installation location is to uninstall the plug-in. The package manager handles installation, updating and uninstallation.

We settled on the current location under %AppData%\McNeel\Rhinoceros because it works well for those with limited access to their computers due to corporate IT policies. The Rhino Installer Engine has always installed files to this location too.

This is a tough one. Food4Rhino has a policy of manually scanning newly published plug-ins (and other content, I believe) before approving them, but this slows down the publishing process. It’s also very hard to detect malicious intent in a plug-in without the infrastructure that an App Store like Apple has! There’s a long history of sharing plug-ins on forums, particularly for Grasshopper.

I do see that currently it’s impossible to manually download a package without unpacking it and in some cases immediately loading it. The best option right now would be to use the Yak CLI to install the package with Rhino closed, then navigate to the installation directory (the list command will also tell you where this is) and perform your own anti-malware checks. I’ve logged YAK-262 to see if I can make this easier and more discoverable for other users that want to do the same.

One more thing to note on the topic of security is that in order to publish a package to the McNeel package server you must authenticate via Rhino Accounts. This gives us some recourse in the rare case that someone publishes malicious or offensive content.

Currently there’s no link between your Rhino Account (assuming you’re logging into Rhino) and the packages that you install, but it is something that we’re thinking about for the future. We haven’t thought much beyond the ability to synchronise packages across different machines that you’re logged into with the same Rhino Account. If you have ideas then I’m all ears.

4

An optional post-download event in the Yak manager where we could invoke a virus/malware check?

// Rolf

5

The .NET framework already does does. See antimalware scanning on this page

6

Hi Rolf,
Thanks for the tip on this, my c drive is getting attacked by music software libraries that are in the gigs. Each library is huge. I’m hoping this will work for my music libraries but I wonder about the latency issues of going from ssd to 72 rpm hard drive. I’ll have to look into it.
Thanks again,
RM

7

Hi @will

Thanks for your detailed reply. I was trying the PM since I saw the icon in new in V7 and was happily surprised I could easily down load Dales plugin thus I instantly became interested.
I didn’t know it’s primarily for GH but that makes a lot of sense. Thanks for testing the symlink and for considering setting a custom directory as a wishlist.

Also thanks for the information on security I not too worried with McNeel it was just a thought since it was so easy to install plugins using the PM.

My new experience with native instruments is that all you pay for is online in your account and you log in to the Native access manager and download or update all you have purchased it’s also a licensing area where you authorize purchases. I guess this is similar to the zoo but you never ever have to check in license once installed and your software always works.

I’m also going to try east west composer cloud which is based on a yearly payment of 200 dollars but you get access to all their software costing around10,000 This is really cool in one way. I’ll have to see how it goes.

One consideration is McNeel offer a similar service where we could get all McNeel’s plugins like bongo and any third parties, cam software etc. that we could rent or pay monthly/yearly fees for but are not too pricey. For those of us who want to use these softs maybe only for a limited time but can’t afford the full package.

Thanks for your detailed reply and for your hard work on this. I don’t do much GHing but I like what your doing with this.
RM

8

Right now, the package manager is designed to work well with free plug-ins and plug-ins that are free to download but require a license to unlock functionality – the same way that Rhino works! The same tools that we use for distributed licensing (Zoo, Cloud Zoo) can be used by plug-in developers. We make the licensing technology, SDKs and support available for free.

There are no plans to offer subscription pricing. Bundling third-party plug-ins with Rhino is a decision that is left to local resellers.

It’s always interesting to hear how other software companies handle cloud, licensing and plug-ins, so I really appreciate your feedback! I do hope to explore how the package manager and Rhino Accounts can interact in the future, but I keen to keep licensing separate :).