Publish to PyPI
boswelja opened this issue · 4 comments
It would be super cool if we could use this easily as a dependency in other projects. Consider publishing to a package index like https://pypi.org/
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?
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.
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....
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()