compas-dev / compas-dev/compas
Unittests for compas_rhino.conversions
- Dominant language
- Python
- Stars
- 386
- Forks
- 122
- Avg merge
- 11d 46m
- Merged PRs (30d)
- 1
Description
Continuing the discussion started in https://github.com/compas-dev/compas/pull/1052.
As suggested by @brgcode, it can be beneficial to have the functions in `compas_rhino.conversions` tested as part of the build.
These are not currently being tested due to their context specific nature, e.g. they contain imports of types from `Rhino.Geometry` which is only available when the code is run in the integrated Ironpython environment of Rhino.
One potential approach is using `rhino3dm` which offers a C++ python binding, mirroring at least parts of the `RhinoCommon` library. It also provides API for reading `.3dm` files.
* By patching `sys.modules`, the required types from `Rhino.Geomery` could be imported from `rhino3dm` instead. However, it seems that e.g. for the type `Box` only one of the 4 constructors available in the .NET type are made available in `rhino3dm`. The constructor used in in `box_to_rhino` is not available.
* Another suggestion is to prepare `.3dm` files with shapes and test their conversion to compas types. This should be doable but would only offer testing conversion from Rhino to COMPAS and not the other way around.
Alternatively, [rhino.inside](https://github.com/mcneel/rhino.inside-cpython) provides access to the Rhino runtime from CPython. This allows importing`Rhino.Geometry` directly, given that a running instance of Rhino is available. No hacking `sys.modules` is required here and all of the `Rhino` namespace should be available. Downside is, of course, that since it requires a running Rhino instance, such tests will only be able to run locally.
* Same constructor issue seems to be happening with this one as well, whatever wrapper is offered inside Ironpython to constructor overloading seems to not be available here.
Contributor guide
Assessment
This issue has not been assessed yet.