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 
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.
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 
4 Likes
and it seems to translate quite well:
Arabic:
الباكا
Bulgarian:
алпака
Catalan:
Alpaca
Chinese Simplified:
羊驼毛
Chinese Traditional:
羊駝毛
Czech:
alpaka
Danish:
Alpaca
Dutch:
Alpaca
English:
alpaca
Estonian:
alpaka
Finnish:
Alpaca
French:
alpaga
German:
Alpaka
Greek:
αλπακά
Haitian Creole:
alpaga
Hebrew:
אלפקה
Hindi:
अल्पाका
Hmong Daw:
alpaca
Hungarian:
alpaka
Indonesian:
alpaka
Italian:
Alpaca
Japanese:
アルパカ
Klingon:
alpaca
Klingon (pIqaD):
Korean:
알파 카
Latvian:
Alpakas vilna
Lithuanian:
Alpaka
Malay:
alpaca
Maltese:
alpakka
Norwegian:
Alpaca
Persian:
آلپاکا
Polish:
alpaki
Portuguese:
alpaca
Romanian:
alpaca
Russian:
Альпака
Slovak:
alpaky
Slovenian:
alpaka
Spanish:
alpaca
Swedish:
alpacka
Thai:
อัลปากา
Turkish:
alpaka
Ukrainian:
Альпака
Urdu:
الپاکی
Vietnamese:
alpaca
Welsh:
alpaca
1 Like
As the global Rhino platform lead for Woods Bagot it would be nice to be able to author a global config while allowing for various local overrides (per studio/region, per project team, etc.) and even nested overrides, such as the global config being overridden by aspects of project team config, which in turn can be overridden by aspects of an individual user config. Examples of this would be the user overriding the author name in Grasshopper document from a generic firm name to their own name, or a team overriding the global default display styles and other visualization assets with stuff specific to their building project.
I think an important step to making installation more uniform would be allowing Grasshopper-only plugins to be compiled as *.rhi files. I think currently the only way for a Grasshopper library to be packaged as an *.rhi is if the installer is also handling a corresponding Rhino plugin (e.g. Weaverbird or Paneling Tools).
@bringley, thanks for the feedback. This is interesting. Please forgive me for quoting myself…
Configuration of Rhino/Grasshopper is outside the scope of this project. However, if that configuration was something that could be (de-)serialised (@brian? @DavidRutten?), then it’s something that could be distributed using a package manager! Would it make your life easier if you could write a config file containing Rhino/GH settings, template files, required plugins, etc. for teams, projects, individuals? I know it would for us, especially when you want to bring someone new into the team/project.
All grasshopper settings are stored in xml files. I do not use the registry for anything. However I do not think the current setting structuring lends itself well for sharing. UI settings which one might want to share and runtime settings which are specific to a user are both in the same xml file.
Thanks Will and David for the feedback.
Will, yes it would be useful to write config files separately for global standards, project teams, and individual users. The current methods we are using to silently install plug-ins along with core Rhino and the scripts that have to be run afterward to handle individual concerns such as Rhino display settings and Grasshopper templates are quite time consuming. (And this goes beyond McNeel stuff, for instance silently installing things like Radiance and Daysim to the C root to get Ladybug/Honeybee running correctly - but I think you have enough on your plate to be worrying about stuff like that…)
David, I’m afraid I don’t know enough about XML to intelligently formulate questions but if there are any methods for authoring or editing (scraping??) XML to help manage large numbers of Grasshopper users please keep us posted. A simple example of the automation I’m looking for is that all users get the same Grasshopper template file by auto-filling the template file directory in the Grasshopper settings, while individual users would have the Author field automatically overridden to match their Windows user name. A more esoteric example would be automatically assigning a subset of users (those working on custom internal toolsets) working directories in the Grasshopper Developer Settings.
It would obviously be nice to configure Rhino and Grasshopper all at once, but even if there were better ways to manage them separately it would still make a huge difference.
@andheum any thoughts?