promote redirectIO

[ewu63]

Purpose

this PR promotes redirectIO to the utils sub-package, so that users can use

from baseclasses.utils import redirectIO

instead of

from baseclasses.utils.redirectIO import redirectIO

Expected time until merged

Hopefully the same day since there will be a failed test which depends on this.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (non-backwards-compatible fix or feature)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Documentation update
• Maintenance update
• Other (please describe)

Testing

None

Checklist

• I have run flake8 and black to make sure the code adheres to PEP-8 and is consistently formatted
• I have run unit and regression tests which pass locally with my changes
• I have added new tests that prove my fix is effective or that my feature works
• I have added necessary documentation

[codecov]

Codecov Report

Merging #74 (90e4916) into master (051af87) will increase coverage by 0.29%.
The diff coverage is 24.32%.

@@            Coverage Diff             @@
##           master      #74      +/-   ##
==========================================
+ Coverage   27.79%   28.09%   +0.29%     
==========================================
  Files          26       25       -1     
  Lines        2342     2342              
==========================================
+ Hits          651      658       +7     
+ Misses       1691     1684       -7     

Impacted Files	Coverage Δ
baseclasses/utils/fileIO.py	59.37% <20.00%> (-22.60%)	⬇️
baseclasses/__init__.py	100.00% <100.00%> (ø)
baseclasses/utils/__init__.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 051af87...90e4916. Read the comment docs.

[sseraj]

Two comments:

1. I'm fine with the change, but is this essentially a judgment call about which level to promote the function to? I think I suggested not promoting the functions to @akleb to avoid making this decision.
2. Should we rename redirectIO.py to avoid any confusion?

[sseraj]

2. Should we rename redirectIO.py to avoid any confusion?

Or move the functions into fileIO.py

[ewu63]

Yeah happy to have a discussion about this. I think explicitly calling the file name is a bit silly and unnecessarily adds stuff to runscripts (this is a from pyhyp.pyhyp import hyp situation), so I think promoting to the submodule makes sense to me, especially when there are no optional dependencies that are getting introduced.

[akleb]

I don't really agree with promoting functions. Isn't this the reason that I have problems with MPI getting imported when trying to use geo_utils? Pygeo was importing everything at once?

[sseraj]

After some discussion with @nwu63, we concluded:

1. Functions should not be promoted to the top level package
2. Promoting functions to the subpackage level is fine as long as the function does not introduce new optional dependencies
3. Functions should not share a name with any files in the same subpackage

[marcomangano]

@akleb are you happy with this?

[eirikurj]

I have had this discussion with @nwu63 before, but in general I like the explicit import statements, but I understand the convenience. IMO promoting is too often exploited to mask poor naming of modules/classes/functions (not the case here). That said, I think the guidelines you guys suggest are good. Will wait to merge to allow @akleb to comment.

[akleb]

I am good with sub package level promotion.

[ewu63]

Maybe we can have a discussion on this topic, but the reason I wanted to promote to the subpackage level is because

1. This doesn't corrupt the top level __init__ so there's no worry of randomly importing things by importing the top level package
2. I don't really consider files to be modules in the Python sense because I prefer to have many small files rather than a single file with 3000 lines. In such cases, it becomes difficult to keep track of which file contains which function, but the subpackage is still able to unify everything together
3. The imports just become a bit too long IMO when we include the file, and it doesn't make a ton of sense. For example I'd rather use from baseclasses.problems import AeroProblem rather than from baseclasses.problems.pyAero_problem import AeroProblem.
4. We still have some flexibility in terms of renaming files at the subpackage level without breaking any API

I think this is a good compromise between having everything in the top level as we did before, vs. having fully explicit imports containing the file name. We should, however, phase out stuff in the top level __init__ over time, I think it's probably best for that one to only contain the version info.