intermittent importerror unknown location, module imported as namespace, import from clr works
Sorry for starting a new thread if redundant. I have been a long time user of PythonNet and suddenly I am having an intermittent failure that I can't diagnose, PythonNet == 2.4.0.dev0 from pypi in Conda Python == 3.7.6 from conda main channel msvc 2019 I am using the following repository: https://github.com/mikofski/pv.net When I try to import pv.SolarPosition I get the following error: ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location) I've tried it a couple of ways: 1. add reference to assembly name, doesn't work
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
2. add assembly path to PYTHONPATH or sys.path, neither works
import sys assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin" sys.path.append(assy_path) import clr assy = clr.AddReference("pv") import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) from clr import pv pv <module 'pv' (namespace)> pv.SolarPosition
3. import from clr, always works pv.SolarPosition
dates = ["19900101T12:30:00", "19900102T12:30:00", "19900103T12:30:00", "19900104T12:30:00"] pv.SolarPosition(dates, 32.1, -121.0) 19900101T12:30:00 --> 1/1/1990 12:30 PM 19900102T12:30:00 --> 1/2/1990 12:30 PM 19900103T12:30:00 --> 1/3/1990 12:30 PM 19900104T12:30:00 --> 1/4/1990 12:30 PM 01/01/1990 12:30:00 --> 1.00 02/01/1990 12:30:00 --> 2.00 03/01/1990 12:30:00 --> 3.00 04/01/1990 12:30:00 --> 4.00 1.00 --> 0 2.00 --> 0.01721421 3.00 --> 0.03442841 4.00 --> 0.05164262 Out[35]: <pv.SolarPosition at 0x173cdd71c88>
Even though I still can't import SolarPosition from pv at least call pv.SolarPosition. Weirdly, somehow if I import some other assemblies, which sometimes works, or if I keep trying long enough, suddenly it works, and I can import SolarPosition from pv using method 1 or 2. I don't know why, it's not repeatable. I recently made changes to my visual studio configuration, I only have build tools for 2015, visual studio 2017, and visual studio 2019. I am building using the makefile with visual studio 2019. I have tried compiling with either 2015 or 2017, but it doesn't seem to matter. I am using the native x64 environment. Also, maybe this matters, I started this project in visual studio 2019 as a .net core 3.1 project, and I noticed that it doesn't have AssemblyInfo.cs or a very big csproj file, but since I'm compiling from the command line using csc in the Makefile (see repo) I didn't think that would matter. Also, I tried an older project that I started using .Net Framework-4.5 and it also seems to work intermittently, inconsistently. My suspicion is that I somehow screwed up my .NET configuration, but not sure how or what. Anyway, if anyone has ever encountered this, or has any ideas, please let me know. I'm going a little crazy. thanks, Mark
Hi Mark, My understanding (and I might be wrong) is Pythonnet (Official Compiled Master branch) is *not* compatible with .Net Core and is compatible only with the .Net framework. Is it possible that you accidentally load .Net Framework libraries when you think they are .Net Core ? I spent a lot of time with a similar problem and I finally decided to compile my project also for .Net framework : .csproj: <PropertyGroup> <TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks> </PropertyGroup> There are forks that are supposed to be compatible with .Net Core but I wasn't able to make them work either. I hope it helps, Emmanuel. On Thu, Apr 9, 2020 at 12:46 PM Mark Mikofski <mikofski@berkeley.edu> wrote:
Sorry for starting a new thread if redundant. I have been a long time user of PythonNet and suddenly I am having an intermittent failure that I can't diagnose,
PythonNet == 2.4.0.dev0 from pypi in Conda Python == 3.7.6 from conda main channel msvc 2019
I am using the following repository: https://github.com/mikofski/pv.net
When I try to import pv.SolarPosition I get the following error:
ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
I've tried it a couple of ways:
1. add reference to assembly name, doesn't work
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
2. add assembly path to PYTHONPATH or sys.path, neither works
import sys assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin" sys.path.append(assy_path) import clr assy = clr.AddReference("pv") import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) from clr import pv pv <module 'pv' (namespace)> pv.SolarPosition
3. import from clr, always works pv.SolarPosition
dates = ["19900101T12:30:00", "19900102T12:30:00", "19900103T12:30:00", "19900104T12:30:00"] pv.SolarPosition(dates, 32.1, -121.0) 19900101T12:30:00 --> 1/1/1990 12:30 PM 19900102T12:30:00 --> 1/2/1990 12:30 PM 19900103T12:30:00 --> 1/3/1990 12:30 PM 19900104T12:30:00 --> 1/4/1990 12:30 PM 01/01/1990 12:30:00 --> 1.00 02/01/1990 12:30:00 --> 2.00 03/01/1990 12:30:00 --> 3.00 04/01/1990 12:30:00 --> 4.00 1.00 --> 0 2.00 --> 0.01721421 3.00 --> 0.03442841 4.00 --> 0.05164262 Out[35]: <pv.SolarPosition at 0x173cdd71c88>
Even though I still can't import SolarPosition from pv at least call pv.SolarPosition.
Weirdly, somehow if I import some other assemblies, which sometimes works, or if I keep trying long enough, suddenly it works, and I can import SolarPosition from pv using method 1 or 2. I don't know why, it's not repeatable.
I recently made changes to my visual studio configuration, I only have build tools for 2015, visual studio 2017, and visual studio 2019. I am building using the makefile with visual studio 2019. I have tried compiling with either 2015 or 2017, but it doesn't seem to matter. I am using the native x64 environment.
Also, maybe this matters, I started this project in visual studio 2019 as a .net core 3.1 project, and I noticed that it doesn't have AssemblyInfo.cs or a very big csproj file, but since I'm compiling from the command line using csc in the Makefile (see repo) I didn't think that would matter.
Also, I tried an older project that I started using .Net Framework-4.5 and it also seems to work intermittently, inconsistently. My suspicion is that I somehow screwed up my .NET configuration, but not sure how or what.
Anyway, if anyone has ever encountered this, or has any ideas, please let me know. I'm going a little crazy.
thanks, Mark _______________________________________________ PythonNet mailing list -- pythonnet@python.org To unsubscribe send an email to pythonnet-leave@python.org https://mail.python.org/mailman3/lists/pythonnet.python.org/
Thank but it doesn't seem to work consistently. It worked the first time I compiled it, but then wouldn't work again, similar to the behavior I was already seeing. I don't think adding the other frameworks to <TargetFrameworks> had any effect in this particular situation, b/c I am compiling from the x64 native tools command prompt for vs2019 using csc.exe so I think I'm using the default .NET framework, but I don't know for sure. If I check where csc I can see it's calling from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Roslyn\csc.exe" If I add net45, net46, or net461 or any combination to the project, when I load the solution, it doesn't reference dotnet core anymore, or any framework. So any symbol from System is unreferenced. Maybe I need to add the reference to other frameworks from the project inside Visual Studio. Anyway, for the meantime this workaround seems to work: ``` from clr import pv ``` so I guess I'll have to do that or do as you did and just switch the project to a .NET Framework. thanks! On Thu, Apr 9, 2020 at 4:17 PM Emmanuel Rutovic <manu@upsim.tech> wrote:
Hi Mark,
My understanding (and I might be wrong) is Pythonnet (Official Compiled Master branch) is *not* compatible with .Net Core and is compatible only with the .Net framework. Is it possible that you accidentally load .Net Framework libraries when you think they are .Net Core ? I spent a lot of time with a similar problem and I finally decided to compile my project also for .Net framework :
.csproj:
<PropertyGroup> <TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks> </PropertyGroup>
There are forks that are supposed to be compatible with .Net Core but I wasn't able to make them work either.
I hope it helps, Emmanuel.
On Thu, Apr 9, 2020 at 12:46 PM Mark Mikofski <mikofski@berkeley.edu> wrote:
Sorry for starting a new thread if redundant. I have been a long time user of PythonNet and suddenly I am having an intermittent failure that I can't diagnose,
PythonNet == 2.4.0.dev0 from pypi in Conda Python == 3.7.6 from conda main channel msvc 2019
I am using the following repository: https://github.com/mikofski/pv.net
When I try to import pv.SolarPosition I get the following error:
ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
I've tried it a couple of ways:
1. add reference to assembly name, doesn't work
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
2. add assembly path to PYTHONPATH or sys.path, neither works
import sys assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin" sys.path.append(assy_path) import clr assy = clr.AddReference("pv") import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) from clr import pv pv <module 'pv' (namespace)> pv.SolarPosition
3. import from clr, always works pv.SolarPosition
dates = ["19900101T12:30:00", "19900102T12:30:00", "19900103T12:30:00", "19900104T12:30:00"] pv.SolarPosition(dates, 32.1, -121.0) 19900101T12:30:00 --> 1/1/1990 12:30 PM 19900102T12:30:00 --> 1/2/1990 12:30 PM 19900103T12:30:00 --> 1/3/1990 12:30 PM 19900104T12:30:00 --> 1/4/1990 12:30 PM 01/01/1990 12:30:00 --> 1.00 02/01/1990 12:30:00 --> 2.00 03/01/1990 12:30:00 --> 3.00 04/01/1990 12:30:00 --> 4.00 1.00 --> 0 2.00 --> 0.01721421 3.00 --> 0.03442841 4.00 --> 0.05164262 Out[35]: <pv.SolarPosition at 0x173cdd71c88>
Even though I still can't import SolarPosition from pv at least call pv.SolarPosition.
Weirdly, somehow if I import some other assemblies, which sometimes works, or if I keep trying long enough, suddenly it works, and I can import SolarPosition from pv using method 1 or 2. I don't know why, it's not repeatable.
I recently made changes to my visual studio configuration, I only have build tools for 2015, visual studio 2017, and visual studio 2019. I am building using the makefile with visual studio 2019. I have tried compiling with either 2015 or 2017, but it doesn't seem to matter. I am using the native x64 environment.
Also, maybe this matters, I started this project in visual studio 2019 as a .net core 3.1 project, and I noticed that it doesn't have AssemblyInfo.cs or a very big csproj file, but since I'm compiling from the command line using csc in the Makefile (see repo) I didn't think that would matter.
Also, I tried an older project that I started using .Net Framework-4.5 and it also seems to work intermittently, inconsistently. My suspicion is that I somehow screwed up my .NET configuration, but not sure how or what.
Anyway, if anyone has ever encountered this, or has any ideas, please let me know. I'm going a little crazy.
thanks, Mark _______________________________________________ PythonNet mailing list -- pythonnet@python.org To unsubscribe send an email to pythonnet-leave@python.org https://mail.python.org/mailman3/lists/pythonnet.python.org/
_______________________________________________ PythonNet mailing list -- pythonnet@python.org To unsubscribe send an email to pythonnet-leave@python.org https://mail.python.org/mailman3/lists/pythonnet.python.org/
-- Being deeply loved by someone gives you strength; loving someone deeply gives you courage. Lao Tzu
Good idea, but it doesn't seem to work consistently. It worked the first time I compiled it, but then wouldn't work again, similar to the behavior I was already seeing. I don't think adding the other frameworks to <TargetFrameworks> had any effect in this particular situation, b/c I am compiling from the x64 native tools command prompt for vs2019 using csc.exe so I think I'm using the default .NET framework, but I don't know for sure. If I check where csc I can see it's calling from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Roslyn\csc.exe" If I add net45, net46, or net461 or any combination to the project, when I load the solution in Visual Studio, it doesn't reference dotnet core anymore, or any framework. So any symbols from System are unreferenced. Maybe I need to add the reference to other frameworks from the project inside Visual Studio. The behavior is so intermittent, I can't make it work consistently. One thing I've noticed, is that when it does work, the module representation is: <module 'pv'> and when it doesn't it's representation is: <module 'pv' (namespace)> Anyway, for the meantime this workaround does seem to work consistently: ``` from clr import pv ``` so I guess I'll have to do that or do as you did and just switch the project to a .NET Framework. Thanks! On Thu, Apr 9, 2020 at 4:17 PM Emmanuel Rutovic <manu@upsim.tech> wrote:
Hi Mark,
My understanding (and I might be wrong) is Pythonnet (Official Compiled Master branch) is *not* compatible with .Net Core and is compatible only with the .Net framework. Is it possible that you accidentally load .Net Framework libraries when you think they are .Net Core ? I spent a lot of time with a similar problem and I finally decided to compile my project also for .Net framework :
.csproj:
<PropertyGroup> <TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks> </PropertyGroup>
There are forks that are supposed to be compatible with .Net Core but I wasn't able to make them work either.
I hope it helps, Emmanuel.
On Thu, Apr 9, 2020 at 12:46 PM Mark Mikofski <mikofski@berkeley.edu> wrote:
Sorry for starting a new thread if redundant. I have been a long time user of PythonNet and suddenly I am having an intermittent failure that I can't diagnose,
PythonNet == 2.4.0.dev0 from pypi in Conda Python == 3.7.6 from conda main channel msvc 2019
I am using the following repository: https://github.com/mikofski/pv.net
When I try to import pv.SolarPosition I get the following error:
ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
I've tried it a couple of ways:
1. add reference to assembly name, doesn't work
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
2. add assembly path to PYTHONPATH or sys.path, neither works
import sys assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin" sys.path.append(assy_path) import clr assy = clr.AddReference("pv") import pv pv <module 'pv' (namespace)> pv.SolarPosition AttributeError: module 'pv' has no attribute 'SolarPosition' from pv import SolarPosition ImportError: cannot import name 'SolarPosition' from 'pv' (unknown location)
import clr assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll" assy = clr.AddReference(assy_path) from clr import pv pv <module 'pv' (namespace)> pv.SolarPosition
3. import from clr, always works pv.SolarPosition
dates = ["19900101T12:30:00", "19900102T12:30:00", "19900103T12:30:00", "19900104T12:30:00"] pv.SolarPosition(dates, 32.1, -121.0) 19900101T12:30:00 --> 1/1/1990 12:30 PM 19900102T12:30:00 --> 1/2/1990 12:30 PM 19900103T12:30:00 --> 1/3/1990 12:30 PM 19900104T12:30:00 --> 1/4/1990 12:30 PM 01/01/1990 12:30:00 --> 1.00 02/01/1990 12:30:00 --> 2.00 03/01/1990 12:30:00 --> 3.00 04/01/1990 12:30:00 --> 4.00 1.00 --> 0 2.00 --> 0.01721421 3.00 --> 0.03442841 4.00 --> 0.05164262 Out[35]: <pv.SolarPosition at 0x173cdd71c88>
Even though I still can't import SolarPosition from pv at least call pv.SolarPosition.
Weirdly, somehow if I import some other assemblies, which sometimes works, or if I keep trying long enough, suddenly it works, and I can import SolarPosition from pv using method 1 or 2. I don't know why, it's not repeatable.
I recently made changes to my visual studio configuration, I only have build tools for 2015, visual studio 2017, and visual studio 2019. I am building using the makefile with visual studio 2019. I have tried compiling with either 2015 or 2017, but it doesn't seem to matter. I am using the native x64 environment.
Also, maybe this matters, I started this project in visual studio 2019 as a .net core 3.1 project, and I noticed that it doesn't have AssemblyInfo.cs or a very big csproj file, but since I'm compiling from the command line using csc in the Makefile (see repo) I didn't think that would matter.
Also, I tried an older project that I started using .Net Framework-4.5 and it also seems to work intermittently, inconsistently. My suspicion is that I somehow screwed up my .NET configuration, but not sure how or what.
Anyway, if anyone has ever encountered this, or has any ideas, please let me know. I'm going a little crazy.
thanks, Mark _______________________________________________ PythonNet mailing list -- pythonnet@python.org To unsubscribe send an email to pythonnet-leave@python.org https://mail.python.org/mailman3/lists/pythonnet.python.org/
_______________________________________________ PythonNet mailing list -- pythonnet@python.org To unsubscribe send an email to pythonnet-leave@python.org https://mail.python.org/mailman3/lists/pythonnet.python.org/
-- Mark Mikofski, PhD (2005) *Fiat Lux*
participants (4)
-
Dr. Mark Alexander Mikofski PhD -
Emmanuel Rutovic -
Mark Mikofski -
Mark Mikofski