@gatapia I see that google search points to issue that was happening due to broken python dependency package (not upgraded properly). So if it does not fail during import - this is worse than failing explicitly. How is your use case different? Can you provide a test?

Sorry @denfromufa I tried to make this reproducible but could not. It happened on one machine but not another. I know this little hack fixed the broken machine tho. Unfortunately tracking down this "environment" issues is beyond the time I have to put towards this.

@gatapia do you have any more context, like what 'name' is that's being passed to ImportModule? It feels like there's probably another error that should get caught sooner.

@tonyroberts sorry I don't know; the code I am running imports quite a few modules mostly within the sklearn, pandas, numpy ecosystem. I did not debug this while running I just hacked this fix so I have very little "root cause" information.

Could this be related to this part of the code:https://github.com/pythonnet/pythonnet/blob/master/src/runtime/assemblymanager.cs#L320 ?

I have a patch in my local branch in place that changes this line to not use an empty string but instead"_clr_internal". I'll investigate a bit.

@filmor@gatapia@tonyroberts it may be possible to reproduce this error, if you have partially installed packages like in this case I had in the past:

http://stackoverflow.com/questions/28588776/python-net-name-must-not-be-empty

@denfromufa I tried to reproduce the error on my server after I found that SO question but even then I could not. I reinstalled Anaconda and all my packages and my server still had the error. I could never get a reproduceable case. Again on all dev machines it worked, just on my prod server did it not.

I got a similar error in a Django-related application (Windows 7, Python 2.7.11, pythonnet 2.1.0, Django 1.9.5):

 Unhandled Exception: System.ArgumentException: Name must not be empty!    at Python.Runtime.ModuleObject..ctor(String name)       at Python.Runtime.ModuleObject.GetAttribute(String name, Boolean guess)       at Python.Runtime.ImportHook.__import__(IntPtr self, IntPtr args, IntPtr kw)       at Python.Runtime.Runtime.PyObject_Call(IntPtr pointer, IntPtr args, IntPtr kw)       at Python.Runtime.ImportHook.__import__(IntPtr self, IntPtr args, IntPtr kw)       at Python.Runtime.Runtime.PyObject_Call(IntPtr pointer, IntPtr args, IntPtr kw)       at Python.Runtime.ImportHook.__import__(IntPtr self, IntPtr args, IntPtr kw)

I recreated my virtual environment from scratch in an attempt to rule out incomplete installations, as was mentioned in the earlier SO link. It did not have any effect in my case.

After downgrading to pythonnet 2.0.0.dev1, I was shown a completely different error message originating from Django (an internal server error due to a recently introducedImportError in my Django configuration). When I fixed this Django error, I could run my application with pythonnet 2.0.0.dev1. After once again upgrading to pythonnet 2.1.0, not touching anything else, everything once again ran cleanly.

So, it seems like the .Net exception thrown through pythonnet in my case was not really the root error in my application, but a secondary error due to some part of the .Net stack interacting badly with in my case Django's runtime exceptions.

@dandersson can you please try pythonnet recompiled with this patch from@gatapia and see if it helps finding thisImportError in your old Django configuration? At least it should not hide thisImportError and not fail silently.

Also it would be nice if you can turn it into minimal reproducible example, that is what we are really missing.

@gatapia try running your failing "prod server" using pythonnet 2.0.0.dev1 like@dandersson did - you may find some dependencies silently failing.

also@dandersson and@gatapia can you try applying the patch from@filmor above?

Hi all, I encountered the same problem and could figure out that this happens when someone uses relative imports to check if a specific module is available.

For examplesite-packages\bs4\builder\__init__.py uses:

# Builders are registered in reverse order of priority, so that custom# builder registrations will take precedence. In general, we want lxml# to take precedence over html5lib, because it's faster. And we only# want to use HTMLParser as a last result.from .import_htmlparserregister_treebuilders_from(_htmlparser)try:from .import_html5lib# this line reproduces this issueregister_treebuilders_from(_html5lib)exceptImportError:# They don't have html5lib installed.pass

I usedmatthid@2823941 to fix the issue. See#219

Any chance of this getting merged?

@tonyroberts, can you provide Benedikt Reinartz@filmor with merging rights? I find
his contributions outstanding!

On Friday, June 3, 2016, Benedikt Reinartznotifications@github.com wrote:

Any chance of this getting merged?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#182 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHgZ5U6YdhbmBEgs37uavGZFSSgRZP2qks5qIEuTgaJpZM4HtRJA
.

@filmor I don't think it is the correct fix as it will lead toRuntime.PyObject_Call being called twice instead of properly detecting the error condition earlier.

I'm fine with other fixes, as long assomething gets merged. I don't like having to patch manually to keep this from failing in production :)

Yeah its open way to long :) I hope I can provide a test case for this in my PR this weekend