Homepage GitHub

Migrating the PyUAVCAN CLI tool into a different package

Applications & Usage Pyuavcan
#1

I am planning to migrate the CLI tool from PyUAVCAN into a separate package because it complicates maintenance and violates the sensible design principle “do one thing but do it well”. Doing so is easy because the CLI is barely coupled with the library at all, it only relies on its public APIs.

If the CLI tool is to become a separate entity, it is to require a name. I am inclined to name it u because who has time to type letters in 2021?

u sub uavcan.node.Heartbeat
u call 42 123.sirius_cyber_corp.PerformLinearLeastSquaresFit.1.0 '{points: [{x: 10, y: 1}, {x: 20, y: 2}]}'
u pub 12345.uavcan.si.sample.temperature.Scalar.1.0 '{kelvin: 123.456}' --count=2

If there are any objections, speak up now. The question is relevant right now because I want the first release of PyUAVCAN to be devoid of CLI.

FYI @scottdixon

Edit: upon some deliberation I am inclined to prefer un as an acronym for “uncomplicated” or UavcaN, since this name is actually available at PyPI. I messaged the current owner of the placeholder at u just to check if he is interested in transferring the name to us but the chances are slim.

#2

If I do un <tab> I get a lot of hits. Can we find something that is more distinct? uv <tab> for instance is unique on my mac and brew install uv also shows no results. In general let’s make sure the name is open for ubuntu (apt), mac (brew), windows (I guess? they have something now right?), and pypi. Possible suggestions:

  • unvn
  • uncn
  • uvn

In general, I like the idea that we do not include “py” in the name; advertising this as a stable CLI distinct from the implementation.

#3

There were new developments since my last post. The owner of the u name has kindly agreed to transfer the name over to us but he lost access to his PyPI account. We asked the PyPI admins to do the transfer without having to restore the original owner’s account:

See, if the name is one letter long, you don’t have to press Tab at all. I think that as an emergency exit we could consider a secondary name like utool or u-tool, as in “the U-tool”, along the primary u. Would you stand behind this?

#4

I think it’s a bad idea to name a tool using something like common word or one-letter word. Because it’s very difficult to get relevant pages from any search engine (like Google) when you try to resolve some specific issue. For example there is a BDD tool for python called ‘behave’. And when you try to google for something like 'behave ’ you can get pages for many programs that are unrelated with python, BDD and behave. I don’t like spending my time to reformulate search-phrase to get relevant pages.

It seems to me, that Scott’s suggestion is more usefull. I’d rather prefer something like uavcan-cli. Tabs and history are to rescue for those who finds it too long. If somebody wants to call cli-tool from PyUAVCAN using one-letter word they can allways make an alias for it.

#5

These are valid points. I am not sure if the name “uavcan-cli” meets our quality bar, though.

Also, looking at the name transfer issue I filed last week, we are not going to receive u in the near future anyway.

Here’s one idea: in the spirit of Yukon, how about Yakut(ia)? I’m sure @scottdixon would approve.

1 Like
#6

Seeing as there are no objections, I am going to take yakut as the current working name. If needed we can revise it but it’s better to do it sooner than later.

2 Likes
#7

Sounds good to me!