I am developing a Grasshopper plugin and I am having some trouble packaging the project. I want to use Yak for the distribution and it seems like it is possible to host the .yak-file on a direct download URL. Is this the case? If so I am having trouble with placing the .yak-file å place where the URL will be accepted. I am trying various file sharing services and github but I get json exceptions. On github I get “Could not create SSL/TLS secure channel”, and on the other attempts I get json parsing error. Are there any guides as to how to host the .yak-file via a separate link? Are there any way to install a .yak-file locally? This would be desirable.
It is my impression in this case that it is desirable to use a more conservative distribution, meaning that the plugin is to by default follow the main install of the software. The idea is to try to approximate a user friendly single installation, meaning that the interoperability with Rhino-Grasshopper(and other software) should not require any user action. Along with user friendliness, the plugin itself is made and funded by the software owners/developers themselves and I think they need a more sense of control over the distribution. My impression thus far is that it is difficult to see how product owners can manage their product thoroughly on the Yak-server, and that after the upload the product is somewhat out of their hands. Alternatively, I can make a simple install file, but I would prefer to be able to ask Rhino where the target folders are via a stand alone executable rather than make a robust install which searches through the windows registry and folders. On this issue it seems like there is no API available for stand alone executables to ask Rhino for information without being an installed plugin. But also this installer would have to handle versions and uninstalling as well, which the Yak-server handles.
Also note that missing plugins can be automatically installed via Yak. This currently works after a restart, but next weeks Rhino7 WIP has on-demand plugin loading during gh file opening.
There’s good reasons for taking some control away from developers. Robert McNeel & Associates sits in between developers and users in the plugin market and as such we need to balance our responsibilities. As soon as a plug-in is released and potentially in the hands of an end-user, we want them to feel secure in the knowledge that they will have access to whatever version of a plugin works for them. If developers had the ability to remove versions in their entirety, the plugin ecosystem loses reliability.
I am not sure how much weight taking some control from developers should have, as in this case where the plugin serves as a link between Rhino-Grasshopper and another software, being able to pull versions can sometimes be important if some bug exists in some version of the plugin that cause costly difficult to detect inaccuracies. Also there is the thought that by taking control away, one can argue that you are also taking a larger portion of the responsibility related to the reliability of the product. This is circumvented via a site typically similar to food4rhino, where the developers manage their own content and they can license their products. These types of sites gives also the opportunity to notify all members who have downloaded said plugin about any important notifications. What I hoped the Yak-package would be was a better way to distribute plugins, simplifying installation yet maintaining the ability to manage the distribution.
Ideally if there’s a bug in version x, then people will have the choice to revert to version x-1 if it interferes with their work, or upgrade to version x+1 which has a fix for this bug.
But of course that’s a woefully naive model. A much better description of a software release cycle is that version x contains bugs (a, b, c, d, e, f), whereas version x+1 contains bugs (a, b, e, g, i). Only in exceedingly minimal updates is it possible to eliminate a bug without introducing any new bugs or behavioural changes which would affect the outcome of a process.
A developer may well feel that the removal of bug c is such a hugely important update that she wishes to eradicate version x from reality, but there may be a user who never even got close to c but instead will be shafted by bug g introduced in the ‘fix’.
There are sometimes good reasons for the removal of a version; if it’s an absolutely catastrophic release without an improved, higher version which may still fall into the hands of unsuspecting end-users… yeah maybe then.
I don’t know if we have ways to genuinely remove a release, or somehow mark it as off-limits. @will what’s our process for such a case?
Use the CLI (or REST API) to “yank” the version (preferred). This hides the version so that it isn’t downloadable by anyone unless they know the exact version number that they’re looking for. For example, Grasshopper’s Package Restore feature will still be able to find it but it won’t show up if you run the _PackageManager command in Rhino.
Ask me to delete the version/package. The version/package will no longer exist on the server. This is a last resort, for the reasons David mentioned above.
Beyond the ability to control the availability of your plug-in, what other kinds of control are you looking for?
I think that the yank-functionality is fine and knowing that it is possible to completely delete a version is good if some edge case should emerge. Furthermore I think the Nuget style PackageManager will solve my concerns around plugin installation user friendliness, if I am correct in assuming that this will hande Grasshopper plugins? Is this packagemanager near release? I am having some trouble testing it though as the TestPackageManager command is not yielding any results in my Rhino 6 SR20
Hei Ole Martin - does that mean that you are not getting a dialog box to show up with that command?
What is echoed to the command line? Could you paste the last few lines?
-wim
As a disclaimer, all though I do Grasshopper component development, I am not accustomed to using the Rhino software. I assumed that “TestPackageManager” was to be entered in the Rhino command line. Here is my attempt:
Hi - so far, so good : )
As this is a test command for the time being, this command will not autocomplete and needs to be fully typed into the Rhino command line without any mistakes.
When you do so, and hit Enter, what happens next?
-wim
Ah, yes the PackageManager opens. Thank you! How close is this packagemanager to be relied upon? Pretty soon we are going to decide how to distribute the plugin, meaning decide if we are going to manage the install manually or use the packagemanager.
Hi - I’m sure that @will’ll step in and correct me if I’m wrong, but you should be able to rely on this package manager as it is now. It is a regular command in Rhino 7 and I’m not aware (silly me?) of any major differences that should get in the way of being able to use this to deploy plug-ins.
-wim
No corrections needed, @wim, but I will elaborate . The package manager has been in the wild for a couple of years but the intention is to release it properly as part of Rhino 7. I have a host of tasks that I’m working on right now including support for platform-specific packages and integration with Food4Rhino – features that will make using the package manager much easier. The underlying client/server architecture has been working well throughout this time, though!
That said, I designed the packaging process to be very simple; it wouldn’t be hard to switch to it at a later date if you think that a custom installer provides features that you need right now.
Hi - I’m not sure what you need help with.
It looks like the developer of the LunchBox plug-in hasn’t made that plug-in available for the Rhino Package Manager. That means that you will have to manually download from Food4Rhino and install it.
Does that help?
-wim
. The package manager has been in the wild for a couple of years but the intention is to release it properly as part of Rhino 7. I have a host of tasks that I’m working on right now including support for platform-specific packages and integration with Food4Rhino – features that will make using the package manager much easier. The underlying client/server architecture has been working well throughout this time, though!