dict like output for yaqd status

[kameyer226]

dict like output for yaqd status which can be sifted through for has-dependents or for REPL, script based access of the daemon list

[untzag]

I'm not quite sure I follow your idea, but does yaqd list --format json satisfy what you're looking for?

[kameyer226]

I am importing yaqd_control as a module using REPL, looking to see if yaqd_control.status() could be modified to return a dict or list if a kwarg was added to the method. I thought such a way would be handy to parse through for verifying daemons are running properly at startup with a verifying script, maybe even make them work properly, including shutdown(True)

[untzag]

Personally I vote "no" for this feature. My vision for yaqd-control does not have a python interface and is only interfaced via the command line. Using yaqd-control as a python package is out of scope.

The json format that I mentioned above is great for programmatic access. From Python, you could do something like the following.

import subprocess
import json
def get_known_daemons():
    process = subprocess.run(["yaqd", "list", "--format", "json"], capture_output=True)
    dict = json.loads(process.stdout)
    return dict

By keeping the interface outside of Python we maintain maximum flexibility for the future of the ecosystem.

@kameyer226, can I ask what particular issue you are trying to solve right now?

I thought such a way would be handy to parse through for verifying daemons are running properly at startup with a verifying script, maybe even make them work properly, including shutdown(True)

Where would such a script live? What particular problems are you trying to solve? Maybe there are other approaches that would be best for the ecosystem as a whole.

I'm happy to be overruled by the community if people really have a use for such a Python API 😄

[kameyer226]

What kind of flexibility do you hope for in the future? I don't follow.

[untzag]

I want other languages to have the same amount of access to the yaqd-control API. Trying to structure core tooling in a language-agnostic way. I'm willing to be overruled if everyone agrees that I'm being silly.

[kameyer226]

I'm missing the philosophy behind this. I mean, why not both? It seems like you can satisfy both a language-agnostic and a pythonic access to this problem.

[untzag]

It seems I am wrong. Please open a PR with changes as you see fit @kameyer226

[ksunden]

I think it is out of scope as well for status... its one thing to make access to the cache relatively easy so things like yaqc-qtpy can use the same source of truth without needing to make things more complex by using subprocess call to get a list of available daemons, but basically anything else I firmly feel is out of scope.

I can't really think of a good reason to use status over list (/read-cache) for as a python library... if you need to connect to the hardware, than doing so in your own control is going to be simply better.

[kameyer226]

So,
(1) create a lookup file of daemons you actually need running for a plan
(2) Read the file into a list
(3) Attempt a Client to each one of them
(4) If fail, attempt corrections (i.e., yaqd restart via console) and or point out failures
(5) If all works, greenlight to launch whatever you want to launch

Above requires that GUIs like bluesky-cmds can still operate with a given plan with the limited daemons
(i.e., it won't cause a fail on the queue). If one has such a plan active, will bluesky-cmds run
fine, even if other non-necessary daemons are offline?

[ksunden]

bluesky-cmds does not interact with the yaq cache at all, directly... it gets information about hardware through the queueserver, which in turn gets info from happi.

[kameyer226]

So does that mean bluesky-cmds will run fine, even if other non-necessary daemons are offline?

[ddkohler]

@kameyer226 thinking about the list of steps you wrote for preparing for an acquisition. It looks like a perfectly acceptable steps, and something that could be written into a script to run quite easily. But probably doesn't belong in yaqd-control.

Your concerns have shifted to how bluesky-cmds will handle a set of daemons, where some are "online" and other are "offline". Without the wherewithal to really tackle this in depth, I will say that bluesky-cmds can routinely handle offline daemons that are not necessary to the acquisition. Any issues you are having with offline daemons screwing up the acquisition is a bug. The location of that bug may be in the daemon itself, the yaq protocol, bluesky-cmds...we'll have to dig more to figure out what is going on.

[kameyer226]

I believe that a truly universal mechanism for acquiring data via the yaq-project would be the ability to script commands via yaqc rather than use the GUI, if need be. (Otherwise how could one justify separating bluesky-cmds from yaq-project?) The GUI should just be considered frosting.

In order to use scripts to acquire data, one needs to be able to check that the daemons are in fact working correctly
before they are used. But if they are not working correctly, there should at least be some attempts to get them to work properly. And I would think some of these attempts can be scripted rather than punching away at the console.

Now that all that is on the table, the only real question left is whether or not console commands ('eval') need to be fed in or whether one can construct a library to help.