Skip to content

feat: new CLI architecture #191

Open
@yucongalicechen

Description

@yucongalicechen
          > > I can merge this if you want (it is conflicted so that needs to be fixed) but my concern is that the CLI is not the way we want it so we can't release this way. Do you want to fix things on this PR or another one?

I can resolve the conflicts here so we can merge this PR, and address the CLI issue in a separate PR. Do you prefer to keep the different muD computation methods within getmuD only (as we discussed in #181)? I think it is also helpful to give users the option to compute muD during the correction.

yes, I am working off the understanding that we are being guided by the discussion in #181. However, if we have this structure for getmud it kind of implies that there will be a similar construction for something with a name like getcorr or applymud, unless you can think of a better way of doing it.
labprdfproc getmud -c NaCl -e 25
labpdfproc applymud [file1.xy, file2.xy] --mud 1.8
labprdfproc applymud [file1.xy, file2.xy] -c NaCl -e 25 -d 1.5
something like that (this is not a complete list but just examples).

Originally posted by @sbillinge in #189 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions