Rhino Package Manager

Serengeti (Rhino WIP)
1

I’m extremely excited to be kicking off discussions for a cross-platform package management system (client and server) for the Rhinoceros platform. I had many an interesting chat whilst in Barcelona about scenarios that I could see directly benefitting from such a system. Below is a slightly sanitised version of the notes I took during the conference. This is only a starting point, everything is up for discussion at this stage. I’m kicking things off in Serengeti to involve as many people as possible (within reason) – so please give us your thoughts.

But, before I start blabbering on, I should probably introduce myself quickly for the benefit of those of you that I haven’t yet had chance to meet. I’m Will Pearson. I’m from the UK and work in London as a structural engineer/computational designer/software developer. I’m delighted to have recently joined the McNeel team (albeit in a limited capacity) to work specifically on this project. I’m fascinated by the processes involved in developing software, from IDE to CI, so a package manager is right up my street! I’ve also dabbled with a variety of modern languages, each with their own solutions to installing dependancies, and will try to use this to approach this project from a holistic perspective.

So, back to the discussion at hand, what ‘packages’ could we potentially ‘manage’?

  • Rhino/Grasshopper plugins*
  • Rhino models
  • Rhino templates
  • Grasshopper definitions
  • GH user objects and clusters
  • RhinoPython/GhPython scripts
  • Rhino blocks
  • materials, environments and textures
  • anything else?

* As I see it, small to medium sized Rhino/GH plugins should be the main priority, e.g. the type that currently exits on Food4Rhino and perhaps slightly larger ones, looking for a more tightly integrated delivery system. The current problem with these plugins is that installing them is either a manual task, or the onus is on the developer to roll their own installation system which can lead to plugins scattered across the filesystem. We need a system that takes the user from discovery through to use in one simple, common step.

Building on top of this central goal, the following hopes and/or dreams are of slightly more specific nature, mostly stemming from discussions with other developers/users in Barcelona:

  • option to automatically install Grasshopper plugins when missing dependancies are detected on loading a definition (in the case of old definitions, the ability to rollback plugin versions)
  • automated configuration of plugins, templates, etc. when provisioning new machines or starting new projects (perhaps using something akin to Pip’s requirements.txt or RubyGem’s Gemfile)
  • internal distribution of tools and files
  • loading multiple versions of Grasshopper plugins to make it easier to load new and old definitions
  • integration with the current Rhino Installer Engine

These are all worthy of consideration. My personal feeling is that this system should be highly flexible and configurable, allowing for scenarios such as:

  • configuration of local package folder(s) (system vs. user vs. network) to reduce disruption of existing workflows
  • the possibility for self-hosted servers, allowing private repositories to exist behind company firewalls
  • the potential to do things (within reason) that we hadn’t even considered

There should also be several interfaces:

  • Rhino command line
  • standalone command line
  • Rhino UI (to cover GH also)
  • web gallery (re-purpose Food4Rhino to work more like rubygems.org (for example), perhaps with protocol handlers for one-click installation? (Nice idea @brian :))

The packages themselves should have a simple yet flexible manifest spec containing all the usual suspects metadata-wise (id, version, author, pre-/post-install scripts, etc.) as well as dependancy information (including, dependancies from other sources, such as NuGet, perhaps).

A couple of general questions:

  • Could and/or should it work with the Zoo and other licensing systems?
  • Should the McNeel repository be moderated (Food4Rhino current operates an approval system AFAIK)
  • Should this link in some way to http://www.rhino3d.com/resources/?

Some “nice-to-haves” that I’m personally a little bit excited about:

  • exposure of NuGet feed to allow plugins with APIs to be easily referenced within .NET projects
  • allow specification of VCS revision (i.e. git SHA) in place of version for open source projects that (a) do not require compiling, i.e. models, scripts, definitions, or (b) hook into a common continuous integration system, or © could be built at install-time if development dependancies are satisfied.
  • ability to group packages (see base-devel on Arch Linux)

Finally, below are just a few reference package management projects:

If you have any thoughts on the above, perhaps a scenario that you think could be solved by something I’ve said, please reply and let’s get this discussion rolling. I’m hoping there are others out there who are as excited about this as we are!

P.S. I’m also accepting codename suggestions :wink:

P.P.S. Here’s a link to the meta-issue over on youtrack: http://mcneel.myjetbrains.com/youtrack/issue/RH-29026

2 Likes
2

“Chimera” It’s all animals at once! It’s even used in Paleontology, i.e. the study of older versions of animals.
“Mosaic” is another term used in genetics which is (very) loosely related to organisational issues.

K suggested “Packrat” and “Hamster”.

1 Like
3

Product/Project Name Checklist (not all apply in this case)

  • Without trademark problems
  • Web address available
  • Works in most languages without translation
  • Easy to pronounce and spell in all languages
  • Sounds about the same in all languages
  • Not a disgusting or confusing meaning in some language
  • Google does not return something disgusting or confusing
  • Easy to remember
  • Related to our other product names
  • Doesn’t sound like a competing product’s name
  • Fun
4

Materials
environments

And while we’re expanding the scope into dreamland - could core Rhino binaries eventually be distributed with this system? That would mean that a user might download the package manager and then run:

RHPM.exe firefly 1.3.17
(to get firefly)

and magically all the rest of Rhino, Grasshopper, any other components would be installed to support version 1.3.17 of firefly.

Of course, this is a long-range, and maybe never kind of an idea, but I’m sure Francis and Adam would drool over such a system.

5

Of course. I’ll add these to the list.

I think it’s important to get all possibilities down on paper then reduce it to a feasible subset, with scope for future expansion.

6

This might be a long shot, but as long as we’re talking about another centralized repo of useful Rhino content (in addition to this forum and other McNeel reference sites)…Having a unified interface for documentation and training materials could be super useful (especially for new users). Although it may be viewed as the author’s duty to maintain helpful documentation in their own distributions (i.e. PDFs that get zipped into plugin directories), having a quick way to access this material, in addition to video tutorials, sample models etc. right in rhino could be really cool. There’s plenty of great training content out there, both official and unofficial that could be codified and exposed to users with even less effort than a google search. Maybe there’s a way to have a more unified Rhino help menu that’s subcategorized into help topics on built-in functions, plugins, scripts, etc that would have hyperlinks per topic (think similar to the current help browser, but more of a linear combination of that and a full-fledged html5 browser). I want all the prettiness and user-friendliness of Chrome but limited to the Rhino universe (or perhaps to the subset of packages the user has installed)

edit: This involves an effort to build and maintain a database of all videos, blogs, etc. that contain useful Rhino content whether official or not

Name suggestion: Since “Zoo” is already taken, “Menagerie”?

7

I haven’t thought about this. It is definitely something to keep in mind while we come up with a plan.

I have always somewhat assumed that the Food4Rhino server would be the location where the typical Rhino installation looks. Food4Rhino could handle submission and moderation and maintain the server portion of the package manager. My assumptions could be totally incorrect though.

Yes, we have already done some work with Food4Rhino to provide us a REST api that our resources site could use.

Man, this could be a really big project… but fun and useful :slight_smile:

8

I’m not even sure what this means. The zoo is for licensing, the package manager is for installation and updates. What relationship do you see there?

I think that so long as the package manager has a way for Food4Rhino and/or the resources page to get (and maybe set) data, we’re good. I don’t think having a deep integration with either system will result in very good design of the package management piece.

9

Other possible data may include GH documentation and maybe localization. Documentation will in all likelihood consist of a lot of loose files (both text and image and *.gh) organised in folders. We have no idea yet how or if we’re going to localize Grasshopper, but when it does happen, I’d very much like for it to be simple textfiles, so we can crowd-source the project.

10

Maybe Display Modes while we are at it.

3 Likes
11

I was wondering how it would work were someone to install a paid-for plugin, compared to one that is free/open source. Would there be any extra steps that the package manager would have to handle? The more I think about it, the more I think that there wouldn’t be…

Whilst I don’t want to undo the work that has been done so far with F4R, I could see it being re-written with all the back-end services handled by querying the package management server (which would, of course, have it’s own HTTP/JSON api).

12

I agree wholeheartedly with this approach. It works. Back to the topic at hand, documentation is an interesting one that I hadn’t considered. My first thought is that it should be made available to view online (with the ability to view old versions) and thus wouldn’t need installing.

13

Zoo as a Rhino download server
http://mcneel.myjetbrains.com/youtrack/issue/ZO-24

14

Worksession files
Themes
RUI files (Toolbars)
RhinoOptions ( think: Aliases, Startupscripts, Displaymodes, …)
Definitions for (Dimensions, Linetypes, LayoutTemplates, Hatches …)

-Willem

2 Likes
15

Thanks for all your suggestions.

@defterGoose you’ve reminded me of how ruby pulls down documentation for each gem that is installed. Interesting. Seems like documentation is high on people’s lists! I’m not sure it’s entirely within the scope of this project but certainly something that we could support if this direction was chosen.

16

I moved 3 posts to a new topic: Dates on Documentation and Articles

18

I’ve never used Ruby, but yes, that does sound similar to what I was proposing. I agree that it does seem a little peripheral at first, but it’s pretty closely in line with giving people easy, immediate access to a large pool of tools. It’s humane to help people not fall on all the new swords they have access to. Many similar repos curate and impose quality restrictions on the packages they host (MELPA comes to mind), so some minimum requirement on documentation could really help foster adoption and development of quality tools.

This seems like a pretty ambitious project, as it could be a whole new discovery/delivery platform, and I’m very excited about it. It seems important to carefully consider how the outward-facing portion comes off to the average user. That way no one is required to have any prior knowledge regarding the existing information sources for Rhino and its many extensions. At a minimum, making it a portal to the existing information hubs on top of a delivery tool would make it immensely useful.

19

Best quote in a long time!

20

I am all for this although I don’t actually think that restrictions are necessary or indeed desirable (beyond the obvious “name”, “version”, “author”, etc.). For example, if we were pulling documentation out of packages and presenting it in a beautiful way then I believe it would encourage more developers to include good documentation.

MELPA looks awesome. Is that mithril.js returning packages as you type? Very nice. The Github repo includes some good documentation too.

I hope so :slight_smile:

21

Unfortunately no. The way we designed the documentation means that different people will have different content (they may have additional docs because of plugins they’ve installed, or because of some language pack, or because their teachers have added some for a course). The doc content is just plain text which is parsed and modified at runtime. For example component names, icons, previews, example file previews, links to other content, …, that’s all stuff that Grasshopper knows how to make so the documentation authors don’t have to. In addition it may also differ from user to user, if they use different display schemes. So the stuff does have to be available locally

We assume plugin docs to be installed along with the plugin, so I suppose that should already work along with versioning.