snmpsim holds back newer pysnmp versions

[svenpanne]

Is your feature request related to a problem? Please describe.

Using snmpsim and pysnmp together results in pysnmp being tied to some 6.x.x version (6.2.6, to be exact). This is quite unfortunate, because one can't use the 7.x.x versions then.

Describe the solution you'd like

Adapt snmpsim so that it works with recent pysnmp versions.

Describe alternatives you've considered

No response

Additional context

No response

[lextm]

It is necessary to explain the purpose for requiring that, as ourselves currently don't know such a scenario.

Given the breaking changes planned in upcoming PySNMP 7.x releases, we have decided to defer the migration of these tools for the time being.

[svenpanne]

Well, I hoped that the purpose is very obvious: If you have a project with both snmpsim and pysnmp in your virtual environment, you're stuck with the old pysnmp forever.

[lextm]

As maintainers, we expect

1. Users run snmpsim separately to emulate SNMP agents, where they don't really care what version of pysnmp is in that project.
2. When users need to select a specific version of pysnmp, they’re building their own SNMP applications, which shouldn't require snmpsim in the same project.

That's why we want to learn from you more details of your project. If you can explain further, we might reconsider the priority (currently set to low).

Besides, snmpsim won't forever stick to PySNMP 6.2, because now PySNMP has lifecycle statements for all releases and we will upgrade it to 7.x before the end-of-life date of 6.2.

[svenpanne]

In our project we have integration tests using snmplib and we have code using pysnmp. The virtual environment we use contains both packages, and I have a hard time believing that this is a very uncommon setup. Giving every tiny tool its own venv/container/whatever to work around such dependency problems does not scale at all.

Regarding the lifecycles: AFAICT this would mean that every project which uses both packages will effectively be pinned to 6.2.6 for another 11 months, right? At least if snmpsim is not updated in the meantime.

[lextm]

Our current plan is to stabilize the API surface on the 7.1 branch. Therefore, it is likely that snmpsim will transition directly from PySNMP 6.2 to 7.1. While we do not have an exact timeline for this transition yet, it is essential for us to complete it before the end-of-life date of PySNMP 6.2.

Nevertheless, if we were to support scenarios similar to yours, we may need to release at least three versions compatible with PySNMP 6.2, 7.0, and 7.1 respectively.

After careful internal discussions, we have decided to classify this scenario as unsupported. We believe that it is very common to run multiple virtual environments for the same task.

[svenpanne]

Hmmm, that's very unfortunate that the scenario is suddenly declared as being unsupported. I still find it hard to believe that it's uncommon to use snmpsim and pysnmp in a single project in a single venv. Having separate venvs for every tiny tool is simply not an option for non-trivial projects, Checkmk for example pulls in >380 packages, ending up with >150 executables in the venv.

And if every release of 6.2, 7.0 and 7.1 breaks something API-wise, it would simply be good to have working snmpsim versions for each of those releases. You expect, after all, your library "customers" to adapt their SW to those changes, so I guess you could do that for your SW, too. :wink:

[lextm]

Our priority is to serve a group of commercial customers that depend on PySNMP/PySMI/snmpsim, and none of them has such a requirement. So, we don't currently consider your request "common". Things might change in the future and we will adapt accordingly.

Another option you (or anyone in a similar situation) might consider is to fork snmpsim on your own and create the releases for your integration testing.