Numpy install breaks CamSchnappr

If you have numpy installed to your default python install and you then try to use camSchnappr then you get import errors.

Uninstalling the native python Numpy fixes this issue. I’m not sure whether this should be classed as a bug or not?

I would hope this would be fixed.
Numpy is an invaluable library.

We ship with a version of numpy, so you have access to it. Why it’s conflicting with the installed one is something we’ll look into though

Hey,

could you give us a bit detail on what versions of Python and Numpy you are running?

Thx
Markus

There are related numpy issues (the reverse case of this i think) when trying to utilise machine learning libraries like scikit learn / sklearn. Even if you set an external python path with the newer version of numpy that your lib / module requires, TouchDesigner will still use the older numpy pre-installed unless you mess with sys.path (there’s a forum post about this, writing a script to delete the built-in site-packages from sys.path or similar to force the external numpy to be used.)
Perhaps a feature to deal with whether Internal or External python libs are used first, like a priority?
It could be set in the preferences like the external python path is though honestly it would be nice to keep all these setting per project / .toe … virtual python envs or something.
Then we can avoid all this mess. It’s only occasionally that people need an external python installation and it tends to be very project specific.

Open to suggestions but bottom line is I think we need virtual python environments that can be carried alongside the .toe and an easy way to configure each project to use it, then we can avoid conflicts like this flat out.

+1 For this. I’m building a project with sklearn and would be wonderful to be able to comfortably create projects without conflicting Python versions.

Just gonna big up my native Python environment support RFE:
viewtopic.php?f=17&t=12009

I think we’ll add a toggle that allows you to choose the search order for modules, if your custom module path is searched before or after ours. This just involves changing the order of sys.path, so for now the temp solution would be to modify sys.path to include your site-packages directory before ours.