Now that we are readding the Python compatibility extensions after the massiver reorganization, it would be good to readd the Python tests.
Installation of PythonCall and its Python dependencies on CI was a major bottleneck on test execution time. We improved it by making a separate test group for Python integration tests, but adding the CondaPkg.toml in the test env provoked to install the dependencies always.
Instead, what might be wiser, is to create a new environment in the test/python/ folder, just for the Python integration tests (ideally, it should just contain PythonCall, Tenet and Test as deps) and on CI, directly call the runtests underneath.
For local execution, we can add some code in runtests.jl that runs a new Julia process (just like ]test does) with the same arguments that stacks both test envs.
Now that we are readding the Python compatibility extensions after the massiver reorganization, it would be good to readd the Python tests.
Installation of PythonCall and its Python dependencies on CI was a major bottleneck on test execution time. We improved it by making a separate test group for Python integration tests, but adding the CondaPkg.toml in the test env provoked to install the dependencies always.
Instead, what might be wiser, is to create a new environment in the
test/python/folder, just for the Python integration tests (ideally, it should just contain PythonCall, Tenet and Test as deps) and on CI, directly call the runtests underneath.For local execution, we can add some code in runtests.jl that runs a new Julia process (just like
]testdoes) with the same arguments that stacks both test envs.