- CI moves to .gitea/workflows/ci.yml and calls the shared driver workflow
of NAPALM/driver-standard; .github/ is gone.
- napalm-device-types >=4.21.1 from PyPI (the floor was 0.4.0).
- LICENSE, CHANGELOG, py.typed, SPDX license string, setuptools>=77,
version floors on the dev extra (black is gone), links to git.netork.io;
the README names Python 3.10 and the Gitea CI.
- mypy strict for the package; napalm_fritzbox.fritzbox is exempt for now
(6 errors), recorded in the quality baseline with four long getters.
- Coverage floor 81 % (measured 81.36 %).
- get_wan_status: the catch-all except Exception: continue (B112) now logs
at debug level before the next WAN service is tried, so a swallowed
failure leaves a trace. A module logger is new.
- The "any remote host" placeholder of get_nat_translations is a named
constant with a nosec (B104): an address reported as data, never a
bind. The output is unchanged.
- ruff found nothing left after the mechanical pass.
Mechanical: ruff format, and ruff check --fix with the rule set every NAPALM
driver uses (E, F, I, UP, B at line length 100, Python 3.10). What ruff
cannot fix comes in the next commit.
Drop get_device_warnings. The DSL noise margin and the firmware on offer
are already facts in get_system_config (dsl_downstream_noise_margin,
firmware_update_available, firmware_version); netOrk derives
dsl_snr_low and firmware_update_available from them (netOrk #1111).
With the install fixed, the tests ran and passed on 3.10-3.12, and the job
then failed at the last step: upload-artifact@v4 refuses to run on Gitea
(GHESNotSupportedError).
Every CI run died at "pip install -e .[dev]": pyproject.toml asks for
napalm_device_types, which lives in git.netork.io/NAPALM rather than on PyPI,
and pip found only an unrelated 0.1.0 there. Not one test had run in CI.
The workflow now installs napalm-device-types from git first. The matrix
drops 3.8/3.9 and requires-python says >=3.10, because napalm-device-types
itself needs 3.10 -- the package never installed on anything older.
Replayed in a fresh venv: napalm-device-types 2.0.0 from git, then the
package with its dev extras, tests green.
Closes netork#116.
`get_port_forwards` reports IPv4 mappings and IPv6 pinholes together, which is
right — both are inbound rules someone configured. `get_nat_translations` then
iterated all of them, and that is not: a pinhole is a firewall hole, and IPv6
does not do NAT at all.
The entries it produced were nonsense in two ways. They paired an IPv6 host with
the IPv4 WAN address, and `inside_local` came out as "2001:db8::10:22", where
the last colon is a port separator and everything before it is an address that
also contains colons.
The two failing tests were pulling in opposite directions.
`TestGetNatTranslations` was right and the implementation had drifted past it
when pinhole support landed. `TestGetPortForwards::test_returns_all_rules` was
the opposite: it still expected one rule from before pinholes existed, which put
it in direct contradiction with TestIPv6Pinholes further down the same file.
get_device_warnings() now returns only {code, meta} — severity, title,
message, and action are resolved centrally by netork's
WARNING_CATALOG (netork/core/device_warnings.py), not by the driver.
Also renames meta.version -> meta.latest_version for
firmware_update_available so it matches the netgear driver's shape and
the shared catalog message template.
Christian Manivong