Rhino Package Manager

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).

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.

Zoo as a Rhino download server

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



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.

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

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.

Best quote in a long time!

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:

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.

@DavidRutten I hadn’t actually considered icons, tooltips, etc. I was thinking more along the lines of long-form documentation – i.e. tutorials and examples.

If anyone else has any other reference package management projects, please feel free to add to this list.

Yeah, I remember that request. I’m not sure if the Zoo is really appropriate here, though. Perhaps the package manager and the Zoo could be merged at some point, but I don’t think it’s a requirement.

We are starting to rewrite most of F4R, so it’s time to add whatever is needed to the wish list. Already there is a REST api. We are working on it.

Great! Do you have any documentation for this API?

No yet. We are using drupal 7 as CMS, and its Restful Web Services (https://www.drupal.org/project/restws). But we are at the point of designing the data/entitites layer.

I moved 3 posts to an existing topic: Dates on Documentation and Articles

Hi Will, of course Donkey, Horse, Camel and Elephant are the typical pack-animals (beasts of burden). Dobbin sounds too lovely. Tusker would be cool - just some ideas (and I’ve never tried that beer)

Lightbulb moment. This handsome guy is a Yak.

1 Like

An ALL inclusive PACKage > ALPACA

Fun fact from wikipedia about a ‘spitting code’ metaphor: " alpacas commonly bring up acidic stomach contents (generally a green, grassy mix) and project it onto their chosen targets"

Also, all that fuzzy white hair, and cute eyes, looks so charming and familiar. Want to hug them, just like Uncle Bob :stuck_out_tongue: