Yak for private distribution?


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

Hi @mist,

Let me know if this helps.

– Dale


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",

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:

1 Like

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

1 Like

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?

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

Yes, a package server.

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!

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

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.