Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python interface #54

Open
emilljungberg opened this issue Sep 7, 2023 · 2 comments
Open

python interface #54

emilljungberg opened this issue Sep 7, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@emilljungberg
Copy link
Collaborator

Starting to work on a python interface now, similar to the BART structure. What we need to make this work is a list of what the suffix is for the files generated by each command in order to read in the output files into python again. Is there an easy way to figure this out? Would also need to know which flags for each command that triggers a specific output. I think building a list or dictionary of some kind for this would be easier than having separate functions for each tool that needs to be maintained.

@emilljungberg emilljungberg added the enhancement New feature or request label Sep 7, 2023
@spinicist
Copy link
Owner

spinicist commented Sep 7, 2023

For the majority of commands the output file has -command appended to the end. The exceptions I can find right now are:

  1. precond - user has to specify the output name. VERY happy to change this to fit the scheme.
  2. sense-calib - appends -sense, which conflicts with the actual sense command. Again happy to change this.

Can you spot any others? Turns out I added quite a lot of commands 😅

An alternative to consider is to use the -o name.h5 option that most commands support and specify a set filename to use, such as -o temp_out.h5? That could make cleaning up easier. I'm leaning towards making sure the output names are consistent regardless though.

As to programmatic API discovery, it is trivial to print a list of the commands in JSON or similar. Sadly, it is harder to then get a list of options/flags for each command due to the design of the argument parsing library I used. I think the latter could be done - but I suspect it would be more work than working out how to parse the help text!

@emilljungberg
Copy link
Collaborator Author

Got something quite simple but flexible working #55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants