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
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.
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.
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.
@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’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.
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.
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.
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.
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.
