sDNA_GH

No intentional breaking changes have been made, but a major refactor has been carried out to the packaging process, and the components ('old' GHPython ones) are now being built in Rhino 8.

• Automated API tests
• Experimental installation using pip
• Allows for future installation in Rhino 8 CPython 3 components (currently not possible)
• Available on PyPi

Not fully tested, but works around a major bug in Rhino 8, and runs sDNA_Integral.

Launcher components are the same as v2.9.1's, and will show that version inside their code.

Fixes v2.9.0, in which juncformula and lineformula inputs are now automatically added to sDNA tool components that can use them (all of them except Prepare, Learn and Predict). If either is set to a non-empty string, an advanced config string is formed, regardless of the value of make_advanced.

Runs some setup code on the component, even if the tool for that component is cached.

When the old problematic shared global options state was being used this, wasn't necessary. But with the functional option (sync=false) it's a bug. This rc could be a great UX improvement.

The best practise is still to specify the exact field to be visualised.

However, the default for "field" is now None, not 'BtEn', so there's a small possibility of a breaking change for those relying on this, who also specified a numerical radius. As now field = None causes a search based on field_prefix = 'Bt', the search could pick up BtE500 before BtEn for example.

This is an edge case to let a new convenience helper work, not a major API change, so I have only bumped a minor version number.

More data about the legend provided.

Unicode characters can now be read from and written to config.toml. Previous toml library deprecated in favour of toml_tools v2.0.0

Better supports shapefiles with zero length links, and writing of their data to User Text

Dependency on PyShp switched to a new bespoke fork of it: IronPyShp

IronPyshp uses an OrderedDict to preserve the order of fields in shapefiles.
IronPyShp also correctly reads and writes Unicode strings to shapefiles in utf8 (however the shape file format
only supports 255 byte strings).

Zero length polylines could always be written by WriteShp. The issue was creating a valid zero length polyline in the first place in Rhino.
The degree 1 nurbs curves turned out to be perfect for this, as they are not required to adhere to the same validity standards as polylines.
WriteShp now reads Nurbs Curves and writes zero length ones to shapefiles, but ReadShp also adds them as a fallback if writing a polyline fails. If adding a degree 1 nurbs curve fails, only then is the error handling via the validity conditions.

Adding polylines to Rhino and Grasshopper with very closely spaced points, close to the floating point precision, can cause rs.AddPolyLine to raise an 'unable to add polyline to document' error. These closely spaced points are common in GIS co-ordinate systems and shapefiles from public sources.

There is little documentation available to say what the limits are in Rhino, and from experimenting simply with code snippets such as:
rs.AddPolyline([[840103.7448000005, 826915.3969999999], [840102.0987999998, 826918.7357999999], [840100.6714000003, 826921.5581], [840099.2468999997, 826924.4590000007], [840095.2278000005, 826925.2062999997], [840095.2275999999, 826925.2062999997]])

Rhino can be happy with a 2-point, close points polyline, but than an extra point in that polyline can cause this error too.

Quick patch to test a bug fix. Nominal changes.

Internal Sentinel instances no longer raise Errors when their data descriptor methods are accessed (get, set and delete). A user has found the noisy Sentinels complain when Sentinel.__set__ is accessed. There should be no need for a Sentinel's data descriptor methods to be accessed, so this branch hypothesises this is because isinstance is checking instance variables are not data_descriptors.

Made the folder structure a level deeper to use food4rhino's preferred name convention. Unfortunately this breaks backward compatibility so is a major version change (but luckily the previous release was available for less than 24 hours) but all tests have been repeated and passed.

Outputs deeper data trees from multi-shape entries in shape files
input and output are no longer options, just function args, to avoid async problems when running mutliple sDNA components due to shared state
Referenced geometry can be plotted and written to shapefiles using a Guid (Id) parameter object.
Reads Shapefile Polygons as closed polylines

test_cases.zip
sDNA_GH.zip