Yak for private distribution?

Rhino Developer Yak
1

Hi,

Is it possible to use Yak as a package manager for private distribution?
I’m currently looking for the best way to keep our Rhino & Grasshopper plugin updated across our company. As we are talking quite a lot of offices, where not all of them can be expected to keep track of whether there is an updated version, I was thinking that it would make sense to have it implemented directly in Rhino.

If you have any other suggestions for “Best practice”, please let me know.

Thank you in advance!
Mikkel Steenberg

2

Hi @mist,

Let me know if this helps.

– Dale

3 Likes
3

Is it possible to add a custom http address?
edit: yes it is.

Is there any documentation on the required API?

edit: looks like it’s fairly simple to reverse engineer:

$ curl https://yak.rhino3d.com/packages
[
  {"authors":"LBP Development","download_count":155,"name":"AMDDenoiser","url":"https://yak.rhino3d.com/packages/AMDDenoiser","version":"0.4.1"},
...
]
$ curl https://yak.rhino3d.com/versions/AMDDenoiser
[{
  "authors":"LBP Development","created_at":"2020-10-08T11:04:37Z","dependencies":[],"description":"AMDDenoiser",
  "distributions":[
    {"created_at":"2020-10-08T11:29:43Z","filename":"AMDDenoiser-0.4.1-rh7_0-mac.yak","platform":"mac","rhino_version":"rh7_0","size":null,"url":"https://files.mcneel.com/yak/packages/AMDDenoiser-0.4.1-rh7_0-mac.yak"}

For anyone else stumbling upon this: it’s pretty easy to implement your own server. These are the API’s that needs to be mirrored:

https://yak.rhino3d.com/packages
https://yak.rhino3d.com/versions/<packagename>
https://yak.rhino3d.com/versions/<packagename>/<version>
https://yak.rhino3d.com/search?q=<query>
3 Likes
4

You can point the package manager at a directory and have it behave as if it were a private server.

1 Like
5

Can anyone at McNeel comment on whether or not this api is going to be documented in the future?
Is this going to be an option for plug-in distribution that is supported for developers?

7

Are you thinking about creating your own package server or something else?

8

Yes, a package server.

9

Is there anything we can add to the existing support for private package repositories that would make it work better for you?

I haven’t considered supporting people implementing their own package servers. I’d like to better understand your motivation first!

10

I created a private package server, and it works well for us. Basically we have a plugin that will (probably) never be for people outside our company. It interacts directly with our cloud platform, and modifies resources on them.

I briefly attempted to get the Zoo licensing to work, but I gave up. It was faster to reverse the API for me.

Summary: My use case was a private plugin that only select people should have access to.
Edit: Not on company network, so can’t use a folder.

1 Like
11

A private package server would work well for us, in conjunction with the public one. We have our own private Nuget Server for distributing our internal company libraries, and we use the public one for everything public. It would make sense for Rhino to behave the same. essentially we’d like for each of our GH add-in to publish to our local server through our CI/CD pipelines. The folder solution is probably going to work for us, but it doesn’t solve the distribution problem.

1 Like
12

Hi Will,

I would like a way to pass on the ownership of a plugin. Imagine I publish our company plugin and then I
leave the company … Noone else kan update it anymore then?

image
image736×174 17.7 KB

EDIT: I see this is already implemented here, thanks! :slight_smile:

13

Hi Will, there’s a typoe here

image
image731×194 24.3 KB

the syntax is --platform with double dashes and not single dash

1 Like
14

In our office, we use UNC paths to point to yak packages saved on the company server. This leads to super long waiting times for the package manager to display available plugins:

Accessing these network drives in Explorer is instant.

15

@will Just a ping you to update the guide.
I had the same issue today.

--platform instead of -platform

16

Thanks. Hugo was converting the double-dashes. Should be fixed now!