blender_neuron.blender_neuron.server.NeuroServer import

[ClaytonBingham]

Apparent issue with blender_neuron add-on. After manually sourcing the Add-on zip, it can't be activated because Blender (init.py) can't find NeuroServer.

BlenderNEURON gui dialog therefore says "Not Connected"

[ClaytonBingham]

Apparently if I followed your steps to cythonize, to build my own add-on it worked. But the add-on didn't work right out of the box.

[JustasB]

Hi @bingsome, Thanks for reporting and looking into the issue. Will you post the OS, Blender, and Python versions on which you encountered the problem?

[ClaytonBingham]

Sorry for the delay. I am on x86_64 GNU/Linux, Blender 2.79b, and Python 3.6.7.

[JustasB]

Hi @bingsome, I'm having trouble reproducing the issue. Is it possible you're using a different Python installation than the one that is bundled with Blender 2.79b? When I get the latest x86_64 version of Blender for Linux, the Python version that comes bundled with shows v3.5.3, but in your comment, you mention you have Python v3.6.7.

If that's the Python version that comes with your Blender, can you point me to where you download Blender?

[ClaytonBingham]

I definitely am not using Blender's bundled python...I suppose that could be the issue but is there really not portability between 3.5.3 and 3.6.7?

Your unittests worked great but only after I re-cythonized and zipped the add-on for 3.6.7. Maybe this can be closed but just something to be aware of.

[JustasB]

Oh I see. The issue appears to be the way distutils creates the binaries when it cythonizes the code. For example, I noticed that when I cythonize under python 3.6, the setup.py script creates 3.6 specific binaries:

I suspect this might be the reason why it doesn't find the 3.5 cythonized module when you try to import using python 3.6. And then it does find it after you manually cythonize it under 3.6.

If you know a way around this python-version-specific-binaries issue, please let me know. I was going to add to documentation that when using non-bundled python instances to cythonize manually (what you did). And I'll post a Q on SO to see if someone knows some magic flag I can set.

[JustasB]

Interestingly, if I rename that 3.5 binary to 36m, I get a RuntimeWarning:

So apparently, the binaries are not compatible across minor python versions.

I'll update the documentation to manually cythonize under custom python instances.

[JustasB]

@bingsome I updated the documentation. Take a look at the addon installation steps and the building steps. Let me know if you think these would have saved you some time if they were there when you were first trying to get the addon to work.

[ClaytonBingham]

@JustasB That looks good to me. Your readme in /forBlender was what I found originally so it will be nice to have it in the docs now.

I'm beginning to wonder if there isn't an easier way to mess with the color maps you've chosen as defaults...is it required to cythonize the add-on? Doing that makes it an extra few steps to modify default colors in the proxy server script...I was looking to make the membrane V more dramatic in the render. Because this isn't strictly related to the issue, we can take this convo offline or somewhere else...

[JustasB]

Ok sounds good. I will close the issue.

For the colors, I was planning on extracting the color parameters and other setting-like values to a separate text config file, which could then later be controlled from GUI in Blender and avoid the need to recompile each time, but haven't done it yet. So at the moment re-compiling is the only way to change those.

If that's something that would work for you and you have the room, would you be willing to check in a PR with such change?