trouble installing infoblox-client on Windows 10 via pip install

[keschae]

Seems as netifaces has trouble building and running setup.py

[sarya-infoblox]

Hi @keschae, we have a lot of issues in our bucket right now, I will get back to you as soon as possible.

[sarya-infoblox]

Hi @keschae, I tried installing infoblox-client in fresh setup with python 3.8 and it got successfully installed.
Can you please check again and share logs, error messages.

[keschae]

The problem that I have is with the netifaces module. It seems to want to build that module with MS C++. I am working in a corporate environment where I am not allowed to install the Visual C++ build tools but it seems as though I have a recent version of the Visual C++ 2019 Redistributable. What are my options? Can I use a precompiled binary?

[sarya-infoblox]

Hi @keschae, I would suggest you to use python 3.8 stable version as we are facing netifaces module error in latest python 3.10 version.
you can degrade your python version in visual C++.

[keschae]

This installs fine on Linux (probably MacOS too). Windows is the trouble. In a corporate environment we are not allowed to install Visual C++ build tools. It's best if we have pure Python packages that don't need to be compiled. netifaces probably doesn't do much within the library could it be excluded and still get most of the functionality.

[keschae]

Hi @keschae, I would suggest you to use python 3.8 stable version as we are facing netifaces module error in latest python 3.10 version. you can degrade your python version in visual C++.

Good suggestion I'll try that.

[sarya-infoblox]

Hi @keschae Can you try and confirm if this works for you and if I can close this issue.

[keschae]

No. It doesn't really work for me because there is no longer a Python Windows installer. Only tar.gz updates for Python 3.8. In my company it is the same. I can't go back to Python 3.8. I hope you can remove that netifaces dependency in the future. Otherwise, unfortunately I cannot benefit from infoblox-client.

[sarya-infoblox]

Hi @keschae Here is the solution for installing infoblox-client in higher python version.

install python setup tools
pip install setuptools==58.1.0
Then try install infoblox-client
pip install infoblox-client

Do let me know if this worked for you.

[sarya-infoblox]

Hi @keschae, Can you confirm this the solution worked for you, if yes can we proceed to close this issue?

[keschae]

Running setup.py install for netifaces ... error
error: subprocess-exited-with-error

× Running setup.py install for netifaces did not run successfully.
│ exit code: 1
╰─> [5 lines of output]
running install
running build
running build_ext
building 'netifaces' extension
error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> netifaces

[keschae]

I tried your suggestion of installing a specific version of "setuptools". I still have the same problem as before. As you can see it fails because I don't have Visual C++ build tools. I believe Visual C++ Build tools do not have an open source license. Therefore I cannot install them on my work computer. I can install them on my home personal computer. But this infoblox-client Python module installs fine on my Linux computer.

[sarya-infoblox]

Hi @keschae, we are still exploring the options to resolve this issue, we will target this issue in our next release.

[jobec]

Same issue here.
Client cannot be installed in Python 3.10 on windows because there are no binary wheels built for netifaces.

Getting rid of that massive "oslo.log' external dependency looks like the best way forward. Or at least make it non-default requirement by moving is to the "extra" requirements. The amount of extra packages it requires is mind boggling.

[sarya-infoblox]

Hi @jobec, we are working on the solution but meanwhile can you try the workaround and install visual C++ build tools and setup tools as I have mentioned above.

[jobec]

Sorry, but that's not a feasible option.

1. This package is part of some tooling for a lot of engineers. We cannot require them to install a full Visual Studio suite just for this one tiny module.
2. People cannot install such software themselves causing a lot of back and forth to get it installed. With repeated pain every time someone joins.

[keschae]

The other dealbreaker is this build tool does not have an open source license from Microsoft. It is a more restrictive license and it is not free and open. I would hope you could achieve the same functionality with something that meets has true open source license.

[masq]

Bumping this issue.

It's an issue with python versions greater than 3.8 on Windows I believe, not just a Win10 issue with the package.

I have the same problems as the others; I cannot arbitrarily install things on my machine like Visual Studio because it's a corporate environment where I do not have administrative rights to install arbitrary things. Also, it's an absurd requirement to begin with -- install the entirety of Visual Studio (6GB+) so you can compile one tiny package that just gets network interfaces cross-platform? That's insane.

Also, fwiw, on the PyPI page for netifaces the maintainer says that they cannot maintain the project anymore. Seems like a good time to find a different dependency (or step up and offer to help maintain it!). Or do as others have suggested in this thread and simply move the specific functionality into an "extras" that could be installed if users wanted to install it rather than gatekeeping the entire library behind this one dependency.

Searching through the repo on GitHub, I can't even find where inetfaces is used, so maybe you guys have gotten rid of it in the upstream but it hasn't made it into a PyPI package yet. Fingers crossed.

Edit 1:
So this appears to be a dependency of the oslo.serialization package:

- oslo.serialization [required: >=1.4.0, installed: 4.3.0]
	- msgpack [required: >=0.5.2, installed: 1.0.3]
	- oslo.utils [required: >=3.33.0, installed: 4.13.0]
		- debtcollector [required: >=1.2.0, installed: 2.5.0]
			- wrapt [required: >=1.7.0, installed: 1.14.0]
		- iso8601 [required: >=0.1.11, installed: 1.0.2]
		- netaddr [required: >=0.7.18, installed: 0.8.0]
		- netifaces [required: >=0.10.4, installed: 0.11.0]
		- oslo.i18n [required: >=3.15.3, installed: 5.1.0]
			- pbr [required: >=2.0.0,!=2.1.0, installed: 5.8.1]
		- packaging [required: >=20.4, installed: 21.3]
			- pyparsing [required: >=2.0.2,!=3.0.5, installed: 3.0.8]
		- pbr [required: >=2.0.0,!=2.1.0, installed: 5.8.1]
		- pyparsing [required: >=2.1.0, installed: 3.0.8]
		- pytz [required: >=2013.6, installed: 2022.1]
	- pbr [required: >=2.0.0,!=2.1.0, installed: 5.8.1]
	- pytz [required: >=2013.6, installed: 2022.1]

Which, when looking in Github at this project, is being imported and used in a few places...

1. utils.py where is it using the oslo.serialization's json.loads wrapper as part of its jsonutils module. The code of that is trivial to implement in this client without the need of the dependency weight.

2. connector.py where again, it is just using the jsonutils module for the wrapper of loads and dumps. The only benefit is for the dumps function, which calls down to the non-trivial function to_primative. However, I highly doubt there's much in this function that infoblox-client truly needs, for example there is specific handling of xmlrpc DateTime objects (which shouldn't? come up in infoblox-client???). In fact, within connector, if there was a failure to import the oslo.serialization package, it just defaults to importing the standard lib json package anyways. Which to me implies that the whole thing was really unnecessary in the first place.

They're also using the oslo.logging package, which then has a dependency of the oslo.serialization package. I think infoblox-client can handling logging on its own though, rather than include such a heavy dependency graph for logging.

[jobec]

It's not the infoblox package that uses it, it's the oslo.* dependencies causing it.

infoblox-client it's dependency tree isn't really pretty .... 🙈

(version 0.4.22 because they broke authentication in long running daemons...)

Grab a 🍿 and start scrolling....

infoblox-client 0.4.22 Client for interacting with Infoblox NIOS over WAPI
├── oslo.log >=1.8.0
│   ├── debtcollector >=1.19.0 
│   │   ├── importlib-metadata >=1.7.0 
│   │   │   ├── typing-extensions >=3.6.4 
│   │   │   └── zipp >=0.5 
│   │   ├── pbr >=2.0.0,<2.1.0 || >2.1.0 
│   │   ├── six >=1.10.0 
│   │   └── wrapt >=1.7.0 
│   ├── oslo.config >=5.2.0 
│   │   ├── debtcollector >=1.2.0 (circular dependency aborted here)
│   │   ├── importlib-metadata >=1.7.0 (circular dependency aborted here)
│   │   ├── netaddr >=0.7.18 
│   │   ├── oslo.i18n >=3.15.3 
│   │   │   └── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   │   ├── pyyaml >=5.1 
│   │   ├── requests >=2.18.0 
│   │   │   ├── certifi >=2017.4.17 
│   │   │   ├── charset-normalizer >=2.0.0,<2.1.0 
│   │   │   ├── idna >=2.5,<4 
│   │   │   └── urllib3 >=1.21.1,<1.27 
│   │   ├── rfc3986 >=1.2.0 
│   │   └── stevedore >=1.20.0 
│   │       ├── importlib-metadata >=1.7.0 (circular dependency aborted here)
│   │       └── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   ├── oslo.context >=2.20.0 
│   │   ├── debtcollector >=1.2.0 (circular dependency aborted here)
│   │   └── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   ├── oslo.i18n >=3.20.0 (circular dependency aborted here)
│   ├── oslo.serialization >=2.25.0 
│   │   ├── msgpack >=0.5.2 
│   │   ├── oslo.utils >=3.33.0 
│   │   │   ├── debtcollector >=1.2.0 (circular dependency aborted here)
│   │   │   ├── iso8601 >=0.1.11 
│   │   │   ├── netaddr >=0.7.18 (circular dependency aborted here)
│   │   │   ├── netifaces >=0.10.4 
│   │   │   ├── oslo.i18n >=3.15.3 (circular dependency aborted here)
│   │   │   ├── packaging >=20.4 
│   │   │   │   └── pyparsing >=2.0.2,<3.0.5 || >3.0.5 
│   │   │   ├── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   │   │   ├── pyparsing >=2.1.0 (circular dependency aborted here)
│   │   │   └── pytz >=2013.6 
│   │   ├── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   │   └── pytz >=2013.6 (circular dependency aborted here)
│   ├── oslo.utils >=3.36.0 (circular dependency aborted here)
│   ├── pbr >=3.1.1 (circular dependency aborted here)
│   ├── pyinotify >=0.9.6 
│   └── python-dateutil >=2.7.0 
│       └── six >=1.5 (circular dependency aborted here)
├── oslo.serialization >=1.4.0
│   ├── msgpack >=0.5.2 
│   ├── oslo.utils >=3.33.0 
│   │   ├── debtcollector >=1.2.0 
│   │   │   ├── importlib-metadata >=1.7.0 
│   │   │   │   ├── typing-extensions >=3.6.4 
│   │   │   │   └── zipp >=0.5 
│   │   │   ├── pbr >=2.0.0,<2.1.0 || >2.1.0 
│   │   │   ├── six >=1.10.0 
│   │   │   └── wrapt >=1.7.0 
│   │   ├── iso8601 >=0.1.11 
│   │   ├── netaddr >=0.7.18 
│   │   ├── netifaces >=0.10.4 
│   │   ├── oslo.i18n >=3.15.3 
│   │   │   └── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   │   ├── packaging >=20.4 
│   │   │   └── pyparsing >=2.0.2,<3.0.5 || >3.0.5 
│   │   ├── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   │   ├── pyparsing >=2.1.0 (circular dependency aborted here)
│   │   └── pytz >=2013.6 
│   ├── pbr >=2.0.0,<2.1.0 || >2.1.0 (circular dependency aborted here)
│   └── pytz >=2013.6 (circular dependency aborted here)
├── requests >=2.5.2
│   ├── certifi >=2017.4.17 
│   ├── charset-normalizer >=2.0.0,<2.1.0 
│   ├── idna >=2.5,<4 
│   └── urllib3 >=1.21.1,<1.27 
└── urllib3 >=1.13

[masq]

yep, haha, was just editing my comment to point that out @jobec! Thanks for the full thing though

[jobec]

It"s fixed as easy as moving the oslo packages to an extras_require statement in setup.py...

[jobec]

I see a new release is pending,
please please please @sarya-infoblox fix this!

Python 3.10 is a reality and 3.11 is on the way!

[sarya-infoblox]

Hi @jobec, we are working on a release now and will resolve this issue.

[sarya-infoblox]

Hi @jobec and @keschae,

As of now, we don't have any other solution for this issue. As soon as we are finished with other timelines, we will have a look into it.

[Karthik-13]

Hi team, any update on this issue? My organization is also blocked by this problem

[sarya-infoblox]

Hi, @Karthik-13 we have released our new version of infoblox-client v0.6.0 and it supports python3.9. Can you try our latest released plugin?