Switch from pycryptodome to its library independent variant pycryptodomex #3011

Closed
opened 2025-12-29 18:24:43 +01:00 by adam · 3 comments
Owner

Originally created by @knobix on GitHub (Nov 13, 2019).

Environment

  • Python version: 3.6.9
  • NetBox version: 2.6.7

Proposed Functionality

Change the requirement from pycryptodome to its library independent variant pycryptodomex.

This shouldn't lead to any specific changes to data models, user interfaces, workflows, etc.

Use Case

When Netbox is used outside a virtualenv it can happen that there's a Python package conflict between pycryptodome, which is required by NetBox, and pycrypto, which another package requires (e.g. Salt in conjunction with ZeroMQ).

This is because pycryptodome is meant as drop-in replacement for pycrypto and both packages use Crypto as namespace.

Switching from pycryptodome to pycryptodomex will solve the issue as the latter one uses Cryptodome as package name.

Database Changes

This shouldn't require any database changes.

External Dependencies

Replace the existing external dependency pycryptodome with pycryptodomex.

Originally created by @knobix on GitHub (Nov 13, 2019). <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.9 * NetBox version: 2.6.7 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Change the requirement from `pycryptodome` to its library independent variant `pycryptodomex`. This shouldn't lead to any specific changes to data models, user interfaces, workflows, etc. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case When Netbox is used outside a virtualenv it can happen that there's a Python package conflict between `pycryptodome`, which is required by NetBox, and `pycrypto`, which another package requires (e.g. Salt in conjunction with ZeroMQ). This is because `pycryptodome` is meant as drop-in replacement for `pycrypto` and both packages use `Crypto` as namespace. Switching from `pycryptodome` to `pycryptodomex` will solve the issue as the latter one uses `Cryptodome` as package name. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes This shouldn't require any database changes. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies Replace the existing external dependency `pycryptodome` with `pycryptodomex`.
adam closed this issue 2025-12-29 18:24:43 +01:00
Author
Owner

@jeremystretch commented on GitHub (Nov 15, 2019):

We intentionally dropped support for pycrypto as proposed under #1527 as it is no longer maintained, and do not suggest using it. If you need both libraries installed, NetBox will need to run in its own virtual environment (which isn't a bad idea anyway).

@jeremystretch commented on GitHub (Nov 15, 2019): We intentionally dropped support for `pycrypto` as proposed under #1527 as it is no longer maintained, and do not suggest using it. If you need both libraries installed, NetBox will need to run in its own virtual environment (which isn't a bad idea anyway).
Author
Owner

@knobix commented on GitHub (Nov 17, 2019):

We intentionally dropped support for pycrypto as proposed under #1527 as it is no longer maintained, and do not suggest using it. If you need both libraries installed, NetBox will need to run in its own virtual environment (which isn't a bad idea anyway).

At the outset: Thank you for looking into it and for the feedback. I'm aware that pycrypto is no longer maintained and shouldn't be used anymore. And yet some projects like Salt still use that deprecated library today for some reasons.

While separate virtualenvs would be an option it isn't always the ideal solution for some environments/installations that doesn't use virtualenvs at all.

Please have also a look at following link that gives a good explanation about the differences of pycryptodome and pycryptodomex in a nutshell: pycryptodome vs pycryptodomex

Thus using pycryptodomex would be IMHO a win:win situation for Netbox and various packagers (like myself for the FreeBSD port of Netbox ). Please see also the related issue at FreeBSD's bugtracker 241913 for some more details.

Therefore it would be nice if the decision to switch from pycryptodome to pycryptodomex could be reconsidered from your side.

That said, thank you for creating NetBox and please keep the good work up!

@knobix commented on GitHub (Nov 17, 2019): > We intentionally dropped support for `pycrypto` as proposed under #1527 as it is no longer maintained, and do not suggest using it. If you need both libraries installed, NetBox will need to run in its own virtual environment (which isn't a bad idea anyway). At the outset: Thank you for looking into it and for the feedback. I'm aware that `pycrypto` is no longer maintained and shouldn't be used anymore. And yet some projects like [Salt](https://github.com/saltstack/salt/blob/v2019.2.2/requirements/zeromq.txt) still use that deprecated library today for some reasons. While separate virtualenvs would be an option it isn't always the ideal solution for some environments/installations that doesn't use virtualenvs at all. Please have also a look at following link that gives a good explanation about the differences of `pycryptodome` and `pycryptodomex` in a nutshell: [`pycryptodome` vs `pycryptodomex`](https://stackoverflow.com/questions/48155294/what-is-pycryptodomex-and-how-does-it-differ-from-pycryptodome) Thus using `pycryptodomex` would be IMHO a win:win situation for Netbox and various packagers (like myself for the FreeBSD port of [Netbox](https://www.freshports.org/net-mgmt/netbox/) ). Please see also the related issue at FreeBSD's bugtracker [241913](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241913) for some more details. Therefore it would be nice if the decision to switch from `pycryptodome` to `pycryptodomex` could be reconsidered from your side. That said, thank you for creating NetBox and please keep the good work up!
Author
Owner

@DanSheps commented on GitHub (Nov 18, 2019):

Please see also the related issue at FreeBSD's bugtracker 241913 for some more details.

I read this bug, the TLDR; I got from it is because it is too difficult for a repo that should switch out an out of date/deprecated dependency for one that is currently up to date, you are opening a Issue/PR with Netbox instead to swap out a working dependency for another dependency.

My suggestion, get Salt to fix their dependency instead.

@DanSheps commented on GitHub (Nov 18, 2019): > Please see also the related issue at FreeBSD's bugtracker 241913 for some more details. I read this bug, the TLDR; I got from it is because it is too difficult for a repo that should switch out an out of date/deprecated dependency for one that is currently up to date, you are opening a Issue/PR with Netbox instead to swap out a working dependency for another dependency. My suggestion, get Salt to fix their dependency instead.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3011