minor corrections related to recent python code updates that make the example run

[jf---]

fix up the example

[chenkasirer]

LGTM
@jf--- thanks so much for fixing the example file!

Question: do you think we should make a new example doc for each new release and keep them separates in folders GH_0.10.0, GH_0.11.0 etc,?
Currently we try to update in-place but evidently we often miss stuff and then it's not clear with which version this file goes.

Would love to get your input.

[jf---]

@jf--- thanks so much for fixing the example file!

its a marginal fix ;)
the demo at the compas assoc. event was awe inspiring, love the architecture of the sw; nice & clean.

Question: do you think we should make a new example doc for each new release and keep them separates in folders GH_0.10.0, GH_0.11.0 etc,?

hard to answer: thing is that often, example code isn't ran in CI, and I think that is the issue
the irony in examples (generally speaking) is that its the code 1st exposed to your audience, therefore its key to the project. for pure python examples, I'd say add a few assert statements and then the fact that it runs makes it a viable demo, and add it to pytest. it would be amazing if CI test could be included to grasshopper nodes too, sharing "if it runs its complete" approach?

that was the hugely indirect answer; the direct answer to your versioning question is no 😉

I think that in the compas sphere in general, that too many releases perhaps occur, and its hard for components and dependencies to interact accordingly. It would be welcome to have a rhythm in the compas sphere and perhaps agree that the compas association supports quarterly releases? It could be fun actually, it's a good reason to meet and synchronise.

I'd much rather prefer a quarterly release that's solid and has pinned dependencies.

Versioning introduces another dimension, and it's not fun going back and forth. KISS for now?

[chenkasirer]

hard to answer: thing is that often, example code isn't ran in CI, and I think that is the issue the irony in examples (generally speaking) is that its the code 1st exposed to your audience, therefore its key to the project. for pure python examples, I'd say add a few assert statements and then the fact that it runs makes it a viable demo, and add it to pytest. it would be amazing if CI test could be included to grasshopper nodes too, sharing "if it runs its complete" approach?

I like the idea of adding asserts to the example code!
How I wish Grasshopper becomes first-class in this whole SW pipeline, that's unfortunately far from happening I think. But small steps are being made.. let's see.

I think that in the compas sphere in general, that too many releases perhaps occur, and its hard for components and dependencies to interact accordingly. It would be welcome to have a rhythm in the compas sphere and perhaps agree that the compas association supports quarterly releases? It could be fun actually, it's a good reason to meet and synchronise.

I'd much rather prefer a quarterly release that's solid and has pinned dependencies.

Here I disagree a bit. we have actually been discussing having even more frequent release schedule, even automate it on a weekly basis. Quarterly releases or even monthly can be frustratingly slow for extension developers (myself included). But perhaps this should be about communication. Have well communicated quarterly package with all sorts of tested example file etc. could be a great compromise.

Anyways, KISS for now it is.