add fre dora tools

[menzel-gfdl]

Describe your changes

Adds functionality to interact with dora - (we should think about the best way to test this without polluting dora).
These commands will only work with a valid dora api token.

Issue ticket number and link (if applicable)

Checklist before requesting a review

• I ran my code
• I tried to make my code readable
• I tried to comment my code
• I wrote a new test, if applicable
• I wrote new instructions/documentation, if applicable
• I ran pytest and inspected it's output
• I ran pylint and attempted to implement some of it's feedback

[ilaflott]

looks in the right direction

idk what we can do to avoid polluting dora's database without including some kind of mock DB on dora's end to explicitly address testing cruft.

[ilaflott]

can use globs- e.g. fre/app/regrid_xy/tests/*

[ilaflott]

@menzel-gfdl i'm gonna nit you here more for a good discussion on style regardless of impact. pylint doesn't seem to care, but shouldn't the module import order be, to steal C++ syntax for a minute:

<pystdlib> 
<3rd-party external modules>
<sub modules in this package>

all sub-sorted alphabetically of course, i can't unsee that now

[menzel-gfdl]

I always wonder the same thing too. I guess is the question is, as far as test_subtools.py is concerned, is fre a 3rd party module? I like to view the tests as outside of the package (thus the non-relative imports), but I don't know if I am correct about that.

[menzel-gfdl]

https://peps.python.org/pep-0008/#imports

Is what I did compatible with this?

[ilaflott]

I always wonder the same thing too. I guess is the question is, as far as test_subtools.py is concerned, is fre a 3rd party module? I like to view the tests as outside of the package (thus the non-relative imports), but I don't know if I am correct about that.

This is exactly why I thought i'd stir the pot here- I had not thought of, and I agree, that the question to answer is really, "are the tests part of the package?" In fre-cli's case, for now at least, the tests are considered part of the package. If they're part of the package, then i think the text from the link applies:

"Imports should be grouped in the following order: 
 1. Standard library imports. 
 2. Related third party imports. 
 4. Local application/library specific imports."

so by that logic, analysis_scripts is third-party in this context... though perhaps this feels a little silly because we work on that package so closely. pytest is similarly third-party, but fre.analysis.subtools is the local application import.

just in case it's not clear, this is absolutely a nit and not a blocking issue whatsoever.

[menzel-gfdl]

Sounds good, thanks!