Import "numpy" could not be resolved

getting such errors(could not be resolved) when tried to create custom python library and import libraries like pendulum, numpy etc.
Other libraries like openpyxl are working.
Any solution would be great. Thank you

Could you share your conda.yaml content?

Default python interpreter version is 3.7.5. When i change the interpreter to 3.10.4(system installed)error in custom library is cleared but in robot script all other libraries(RPA.Excel.Application,RPA.Browser.Selenium,RPA.Tablesetc.) except builtin libraries give error as unresolved libraries, which would work fine with 3.7.5 version of python interpreter.

Conda.yaml file content:(have removed some comments)

Define conda channels here.

  • conda-forge


Few notes.

Python 3.7.5 is our tested version. It works well with rpaframework. When using very new python versions, there is possibility that not all required libraries are ported there yet.

Also be aware that prettytable, pendulum and numpy are all available from conda-forge also:

And can you give more information about your “custom library” and what error are you seeing there with python 3.7.5? And when do you see this error? On your editor, or when you run your robot using our tooling?

Seems from version 1.22.0 of numpy python 3.7 is not supported. NumPy 1.22.0 Release Notes — NumPy v1.24.dev0 Manual
So if changing to numpy==1.21.6 might help

Thank you, changing the numpy library version to 1.21.6 resolved the error.
Could you direct me to the source where we can get the library versions supported by robot framework/python3.7.5, because I’m getting similar errors for other libraries(Pyscreenshot, pandas, etc.) as well.

Thanks again.

We are looking to make the python (and probably pip) version jumps soon.
The next recommended python is probably 3.9.13… this just requires a lot of testing on our part.

Compiling a list of libraries that work together is pretty much an impossible task and that is what resolvers like pip and micromamba are trying to do. Even still only the actual execution truly brings out the effects of changes to different libraries.

…so this is pretty much independent of the coding languages, the true dependency management which is when updating dependencies you pretty much need to test asap… when done freeze your dependencies until the next cycle… for which you should have a set cadence. The further back you get the more work there is.

BR, Kari

1 Like