Projects

Four repositories, one toolchain. pysnmp and mibs are what most people use; pysmi and pyasn1 sit underneath and are reached through pysnmp unless you are doing something unusual. Each publishes its own documentation; this page says what each is for and when you would go to it directly.

Note

mibs is content rather than a library, so it has no PyPI distribution and no release line to track. What it shares with the other three is the toolchain, the commit conventions and the documentation theme.

pysnmp

Repository:

pysnmp/pysnmp

PyPI:

pysnmplib

Documentation:

pysnmp documentation

The SNMP engine. It implements SNMPv1, SNMPv2c and SNMPv3 as a manager, as an agent, as a proxy, and as a notification originator or receiver – the same engine in every role, configured differently.

What is inside it, roughly in the order a message passes through:

  • Transport dispatcher. UDP over IPv4 and IPv6, on asyncio.

  • Message processing. One module per SNMP version, following RFC 3412’s split between message processing and security.

  • Security models. Community-based for v1 and v2c; USM for v3, with authentication (MD5, SHA-1, SHA-2) and privacy (DES, 3DES, AES) as pluggable protocols.

  • Access control. VACM, RFC 3415, which is what makes an agent’s view of its own MIB configurable rather than all-or-nothing.

  • SMI layer. MIB modules loaded and instantiated, with the managed-object machinery an agent implements its instrumentation against.

  • High-level API. pysnmp.hlapi.asyncio: one call per SNMP operation, which is what most programs need.

Reach past the high-level API when you are building something that is not a single request – a command responder, a proxy between SNMP versions, a notification receiver that has to survive its own authorization failures.

mibs

Repository:

pysnmp/mibs

Channels:

HTTPS (https://pysnmp.github.io/mibs/asn1/<MODULE>), release archives, OCI images

Documentation:

mibs documentation

The MIB distribution. A distribution pip does not resolve: point pysmi at the published tree and use it live, or install it locally from a release archive or an OCI image – the content is the same either way. It is what lets an engine say IF-MIB::ifOperStatus.1 = down instead of ...1.8.1 = 2, and it is optional: pysnmp starts without it on the standard modules it ships.

Published beside the modules are an OID index and core.db, a SQLite rendering of the whole corpus that answers from an OID to a name, a syntax and an access level without compiling anything – which is what a trap receiver needs and an anchor index cannot give it.

Its documentation covers resolving a name, translating a trap, overriding a module with a local copy, and what each channel carries.

pysmi

Repository:

pysnmp/pysmi

PyPI:

pysnmp-pysmi

Documentation:

pysmi documentation

The MIB compiler. It parses ASN.1 MIB sources – SMIv1, SMIv2 and the de-facto dialects that vendors ship – and writes them out as pysnmp modules or as JSON.

It ships the mibdump, mibcopy and mibcorpus command-line tools, and it can pull sources from a directory, a ZIP archive, or over HTTP, which is how the MIB distribution gets used. Its mibcorpus driver is what builds that distribution.

You need pysmi when you have a vendor MIB and want to refer to its objects by name. You do not need it to run pysnmp: the standard modules an engine resolves at start-up are compiled already and shipped inside pysnmp, so pysmi is an optional extra (pip install 'pysnmplib[compile]') rather than a dependency.

pyasn1

Repository:

pysnmp/pyasn1

PyPI:

pysnmp-pyasn1

Documentation:

pyasn1 documentation

ASN.1 types and codecs: X.208 types, and BER, CER and DER encoders and decoders that can work over a stream rather than a complete buffer.

It is maintained here because SNMP depends on it, but it is not SNMP-specific and never was – LDAP, X.509, Kerberos and a long tail of other protocols are ASN.1 too, and this is a general implementation of the standard.

How they are maintained

All four repositories share a toolchain deliberately, so that a change in one is a change you already know how to make in the others:

  • uv with a committed lockfile; uv sync --locked reproduces exactly what CI runs.

  • ruff for lint and formatting, against a shared rule set, with mypy on top.

  • Conventional Commits, checked on every pull request, because semantic-release computes the version number and the release notes from the commit history.

  • main carries the released line, next is where work integrates. A release candidate is cut from next, a general release from main, and no push releases anything on its own.

Full detail is in CONTRIBUTING.md, which applies to every repository in the organization.