DOC: Improvements of Environment docstring phrasing.

[phmbressan]

Pull request type

• ReadMe, Docs and GitHub updates

Checklist

• Docs have been reviewed and added / updated
• Lint (black rocketpy/ tests/) has passed locally
• All tests (pytest tests -m slow --runslow) have passed locally
• CHANGELOG.md has been updated (if relevant)

Current behavior

As described in #560, the docstring for the Environment.__init__ were incomplete and outdated.

New behavior

The following changes were employed:

• The legacy reference to rail_length was removed;
• The incomplete phrasing of __init__ was improved;
• Minor additions for clarity and references behind Somigliana's formula.

Breaking change

• Yes
• No

[Gui-FernandesBR]

@phmbressan what happened with the git history in this? oh lord, this looks confusing.
Maybe you started from master first and then changed (rebased) to develop?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.87%. Comparing base (7b81e6e) to head (61bf4d7).
Report is 8 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #565      +/-   ##
===========================================
+ Coverage    72.70%   72.87%   +0.17%     
===========================================
  Files           59       59              
  Lines         9618     9590      -28     
===========================================
- Hits          6993     6989       -4     
+ Misses        2625     2601      -24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[phmbressan]

Yeah, I believe I might have messed up this one by mistake. However I noticed our develop is out of sync with master, see #567 .

[phmbressan]

@Gui-FernandesBR I believe with the develop update the commit history seems to have normalized.

[Gui-FernandesBR]

This seems to be a simple PR with small changes, but don't underestimate it.
The Environment class is the first contact that a new user has with RocketPy, so I want to make sure that these docstrings are clear enough.

Thank you so much for your contribution already, and I hope you may consider some of the comments below.

[Gui-FernandesBR]

Btw, when solving a bug please link the open PR in the development section (right side of you github page) so the Pr and issue can be connected.

In this case, the #560

[phmbressan]

Thank you for your review @Gui-FernandesBR. I am still going to solve your comment about timezones, but I would like to ask your opinion on one matter:

• I have implemented a long time ago the methods set_gravity_model and set_earth_geometry. They, paradoxically, do not set anything in the Enviroment classes (they are using to make computations to set in the constructor).
• This behavior is extremely unintuitive given its naming and behavior being quite different when comparing them to other setters in the same class.

This behavior confused me quite some time while writing the docstring and I would almost consider it a code issue. Do you think is worth changing this behavior to something more standard in a future PR or would it be considered a small breaking change and we should only document this peculiar behavior?

[Gui-FernandesBR]

Thank you for your review @Gui-FernandesBR. I am still going to solve your comment about timezones, but I would like to ask your opinion on one matter:

• I have implemented a long time ago the methods set_gravity_model and set_earth_geometry. They, paradoxically, do not set anything in the Enviroment classes (they are using to make computations to set in the constructor).
• This behavior is extremely unintuitive given its naming and behavior being quite different when comparing them to other setters in the same class.

This behavior confused me quite some time while writing the docstring and I would almost consider it a code issue. Do you think is worth changing this behavior to something more standard in a future PR or would it be considered a small breaking change and we should only document this peculiar behavior?

I'm ok with that kind of refactor.

Please keep in mind that there are several setter methods in the Environment class, they should follow a common standard.

However, I don't think this is exactly a priority right now, so treat it carefully.

[Gui-FernandesBR]

Thank you for your contribution, @phmbressan .

I left some other comments, really small ones. Can you check that out please?

Additionally, could you please update te CHANGELOG.md file with your PR?
That would be important for us to keep track on the main files changes.

[Gui-FernandesBR]

LGTM