Publish to PyPI about starlink-grpc-tools HOT 4 CLOSED

I just published starlink-grpc-core on PyPI containing starlink_grpc.py from the newly tagged 1.0.2 release of this project, it can be installed for use by other projects by:

pip install starlink-grpc-core

I have only lightly tested using it outside the conext of the starlink-grpc-tools scripts, but I don't expect any subtle problems, so it should be good to go.

This includes the newly added control functions. I will not be changing dish_control.py over to use those, mostly because that script is currently serving as an example of how to use requests via reflection without the clunky import mechanism that starlink_grpc uses. For the record, though, here is the version of dish_control.py that I hacked together to test those functions:

#!/usr/bin/python3
"""Manipulate operating state of a Starlink user terminal."""

import argparse
import logging
import sys

import starlink_grpc


def parse_args():
    parser = argparse.ArgumentParser(description="Starlink user terminal state control")
    parser.add_argument("command", choices=["reboot", "stow", "unstow"])
    parser.add_argument("-e",
                        "--target",
                        default="192.168.100.1:9200",
                        help="host:port of dish to query, default is the standard IP address "
                        "and port (192.168.100.1:9200)")
    return parser.parse_args()


def main():
    opts = parse_args()

    logging.basicConfig(format="%(levelname)s: %(message)s")

    rc = 0
    context = starlink_grpc.ChannelContext(target=opts.target)

    try:
        if opts.command == "reboot":
            starlink_grpc.reboot(context=context)
        elif opts.command == "stow":
            starlink_grpc.set_stow_state(context=context)
        else:  # unstow
            starlink_grpc.set_stow_state(unstow=True, context=context)
    except starlink_grpc.GrpcError as e:
        logging.error(str(e))
        rc = 1
    finally:
        context.close()

    sys.exit(rc)


if __name__ == '__main__':
    main()

from starlink-grpc-tools.

OK, I will get it set up to publish the starlink_grpc module as a pip package, specifying the handful of dependencies that that module needs. This way I can bypass the package namespace question by just dropping it into top-level.

I'll put some thought into adding the control functions into starlink_grpc, too. The reason I didn't do that when I added dish_control.py is the grpc calls for those are pretty simple, so there's not really much value add there. I guess that same reasoning didn't stop me from adding a function for obstruction map, though....

from starlink-grpc-tools.

I was going to do that some time ago, but the namespacing issues got a little messy and I didn't really want to deal with it at the time. Also, the project dependencies for all the scripts are a little onerous if you only need one of them (or just want the starlink_grpc.py core functionality).

None of that is a fundamental problem, so I am open to doing this, but I'd like to understand better how people are going to use it as a dependency from other projects. Is it just starlink_grpc.py that is needed? Or are the output scripts (dish_grpc_*.py) needed, too, and if so, how are those being invoked?

from starlink-grpc-tools.

Thanks for the quick response! I think as a dependency, all we need is starlink_grpc.py and maybe dish_control.py. Including the output scripts isn't a good idea, at least not alongside the base module due to the extra dependencies you mentioned.

My current use case is a HomeAssistant integration. Right now it's impossible to use this directly due to HASS code quality rules requiring type hints for parameters and return types, I'm happy to try working on this when I get some time, but I'm not confident I can update the dish_grpc_* scripts alongside everything else.
But essentially, the ideal format is a series of functions for retrieving data, and a series of functions for controlling the dish.

from starlink-grpc-tools.