ENH: New Package Structure

[MateusStano]

Pull request type

• Code base additions (bugfix, features)
• Code maintenance (refactoring, formatting, renaming, tests)
• ReadMe, Docs and GitHub maintenance
• Other (please describe):

Pull request checklist

• Tests for the changes have been added
• Docs have been reviewed and added / updated if needed
• Lint (black rocketpy) has passed locally and any fixes were made
• All tests (pytest --runslow) have passed locally

What is the new behavior?

The package structure has been reorganized into the following:

📁 rocketpy
  📁 environment
    📄 environment.py
    📄 environment_analysis.py
    📄 __init__.py
  📁 mathutils
    📄 function.py
    📄 vector_matrix.py
    📄 __init__.py
  📁 motors
    📄 fluid.py
    📄 hybrid_motor.py
    📄 liquid_motor.py
    📄 motor.py
    📄 solid_motor.py
    📄 tank.py
    📄 tank_geometry.py
    📄 __init__.py
  📁 plots
    📁 compare
      📄 compare.py
      📄 compare_flights.py
      📄 __init__.py
    📄 aero_surface_plots.py
    📄 environment_analysis_plots.py
    📄 environment_plots.py
    📄 flight_plots.py
    📄 fluid_plots.py
    📄 hybrid_motor_plots.py
    📄 liquid_motor_plots.py
    📄 motor_plots.py
    📄 rocket_plots.py
    📄 solid_motor_plots.py
    📄 tank_geometry_plots.py
    📄 tank_plots.py
    📄 __init__.py
  📁 prints
    📄 aero_surface_prints.py
    📄 compare_prints.py
    📄 environment_analysis_prints.py
    📄 environment_prints.py
    📄 flight_prints.py
    📄 fluid_prints.py
    📄 hybrid_motor_prints.py
    📄 liquid_motor_prints.py
    📄 motor_prints.py
    📄 parachute_prints.py
    📄 rocket_prints.py
    📄 solid_motor_prints.py
    📄 tank_geometry_prints.py
    📄 tank_prints.py
    📄 __init__.py
  📁 rocket
    📄 aero_surface.py
    📄 components.py
    📄 parachute.py
    📄 rocket.py
    📄 __init__.py
  📁 simulation
    📄 flight.py
    📄 __init__.py
  📄 tools.py
  📄 units.py
  📄 utilities.py
  📄 __init__.py

Other information

Please test manually importing classes/functions to check if everything is working correctly. The hardest part of this was guarantying that all __init__.py files gave the correct behavior.

Also, some parts of the documentation had to be changed. Please review the docs to guarantee nothing is missing.

I could not build the documentation locally and I could not figure out why. It is building in readthedocs though. Im getting some weird importation error which is strange. It would be nice if someone would check if this happening in other machines too.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[MateusStano]

Forgot to mention, but the simulation folder was created for when the dispersion files are eventually added

[Gui-FernandesBR]

I really loved the implementation, thanks so much @MateusStano !!

• I ran all the tests, including runslow option and the examples in documentation. It's all good (a code coverage of 84% was achieved)
• All te imports are working correctly, as you can see by the testing's results
• The docs are being build correctly

The only thing I'd say is that the README can be improved before v1.
Maybe the fluxogram could be improved, for instance...
I'm asking @giovaniceotto to help us.

[phmbressan]

I am just commenting on these lines, however this happens in most import statements regarding the new structure.

Here there was a change from absolute imports to relative imports. Of course, there are use cases for both of them and I would like to point out the main advantages/disadvantages of each option:

1. See the discussion "Absolute vs relative imports"
2. Despite being very old (but still active), the import section of PEP8 (interesting read) used to strongly recommend absolute imports for packages. This comes from earlier Python versions in which relative imports were more troublesome than today. Nowadays I believe there is not a clear recommendation, and both ways are acceptable;
3. Relative imports have the advantage of being shorter and requiring less refactoring if the submodules are rearranged.

Personally, I believe we should keep this relative import implementation since it does not appear to be frowned upon anymore and having some interesting benefits. I just wanted to make sure that the existence of an alternative is acknowledged.

[Gui-FernandesBR]

Good comment,

This is the first time I see this kind of discussion.
I am aware of this now. In the future we can modify the imports if we find it confusing for any reasons.

I agree moving forward with the current relative import.

[phmbressan]

By mistake I skipped the final review comment, so I will make a standalone comment.

The package structure and imports seems much better now, I believe it makes sense and is quite intuitive.

Small suggestions that may or may not be resolved for merging this PR:

• I would import the two classes inside the .compare module in rocketpy/plots/__init__.py instead of using * as recommended by PEP8;

[Gui-FernandesBR]

All problems solved.
Ready to merge it after conflict solving