Confusing dependency advice, and installation instruction is pip only (bug report, sort of)

[gdt]

I'm packaging pygpsclient and deps for pkgsrc, and ran into trouble. While I figure it out, I found several things that seem off about the README:

• it says this is a parser for UBX, NMEA, and RTCM, but I see code only for UBX.
• it says there are not "third-party" dependencies. This is an odd phrase, and as a packager I am not super concerned whether dependencies are from the same author. Instead, I want a list of them, because to package X, I must first package every Y for which X depends on Y.
• installation instructions say pip only. That's fine if people want to use that, but it should be possible to build and install into one's system, instead of a venv just for this.

The good news is that on NetBSD 10 amd64 with python 3.12, after i installed pynmeagps and pyrtcm, tests pass

[semuadmin]

it says there are not "third-party" dependencies.

I'll update the README to clarify that it uses the pynmeagps and pyrtcm packages, though this is implicit in the pyproject.toml packaging file and is transparent to the end user if they use the recommended installation procedure.

installation instructions say pip only.

No they don't - I include instructions for both pip (the de-facto standard Python package manager) and Conda, which between them cover probably 99.999% of target end users (including, as far as I know, NetBSD users). Why would I make things any more complicated than they need to be? But there's nothing stopping an end user from employing a build/installation procedure of their own choosing.

instead of a venv just for this.

You're not obligated to install into a venv 'just for this', and I generally don't myself - the pip installation instructions cover both options. But the use of venv is widely regarded as best practice across the Python community.

[gdt]

Sorry, I unconsciously projected to the null space of packaging systems and ignored the conda mention.
Packaging systems don't allow dependency resolution by pip; they instead depend on that module as packaged. This is necessary for system-wide package upgrades, which are out of the "this is is python and you should use python-specific tools" ecosystem.

I realize people who do packaging for other packaging systems are few in number but there are users behind them. Thus what I really meant at top level is that I would like to see the dependencies listed in the README; thanks for adding that. I did figure it out from pyproject.toml, but had taken the README at face value and thus surprised to have the tests fail spectacularly. But great to have tests; that's part of what they are for and they worked very well (probably with pytest but that's expected).

I was still unclear on "this is a parser for UBX, NMEA, and RTCM", given the list of installed files. Reading the code (I really appreciate the code being writen for readabilty instead of max python wizardry), i see the parsing switch on 3 headers for the three types. Reading pyrtcm, I see how you are avoiding a circular dependency by having enough ubx knowledge to skip those. So perhaps

is a parser for the UBX protocol, that can additionally parse a mixed stream of UBX, NMEA, and RTCM by using pynmeagps and pyrtcm

This may seem too detailed, but in thinking about how to deal with logs from e.g. SparkFun Express, mixed-stream parsing is obviously nontrivial, and it would be nice to know that out of the three, this module is the one that has an integrated mechanism. I see mixed parsing as a headline feature of great interest.