Open chenkasirer opened 2 years ago
If the tests are to be run locally, could we flip the equation and run them from Rhino directly?
I did a quick test, and our ironpython-pytest
thing works correctly inside Rhino:
from __future__ import print_function
import os
import sys
path_to_pytest = r'C:\Users\gcasas\eth\Projects\gramaziokohler\ironpython-pytest\src'
if path_to_pytest not in sys.path:
sys.path.append(path_to_pytest)
import pytest
HERE = os.path.dirname(__file__)
if __name__ == '__main__':
pytest.run(HERE)
Interestingly enough, some tests fail, I haven't looked into the reasons:
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 fromRhino.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 theRhinoCommon
library. It also provides API for reading.3dm
files.sys.modules
, the required types fromRhino.Geomery
could be imported fromrhino3dm
instead. However, it seems that e.g. for the typeBox
only one of the 4 constructors available in the .NET type are made available inrhino3dm
. The constructor used in inbox_to_rhino
is not available..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 provides access to the Rhino runtime from CPython. This allows importing
Rhino.Geometry
directly, given that a running instance of Rhino is available. No hackingsys.modules
is required here and all of theRhino
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.