MAINT: deprecate some methods before v1

[Gui-FernandesBR]

Pull request type

Please check the type of change your PR introduces:

• [*] Code base additions (bugfix, features) : deprecations

Pull request checklist

Please check if your PR fulfills the following requirements, depending on the type of PR:

• Code base additions (for bug fixes / features):

  • 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 current behavior?

There are some functions in rocketpy that either does not work correctly or are already deprecated.

What is the new behavior?

I tried to search in the code for any function or method that we may need to deprecate in the short/medium term future.
I also converted some Environment methods to static methods, avoiding future breaking changes.

Does this introduce a breaking change?

• Yes

Other information

it is not an easy task to imagine if a function would be deprecated in the future or not, but I tried my best here.
If reviewers find time, I also recommend reading all the classes to ensure there's nothing that we could easily modify right now.

** The idea is to prevent for future breaking changes.**

[Gui-FernandesBR]

To discuss before review:

• The Environment Class has these methods called all_plot_info_returned and all_info_returned which is meant to help with the API integration
• Well, I agree it's important, but I have my questions if this is in the right place.
• Maybe we should have a separate file to do the same operation for all the main classes. Just like the utilities.py does: receive a rocketpy class and performs some operations.
• If we keep the function now, but delete it in the future, that would be a break change
• A possible faster solution is to remove its documentation (docstring), thus avoiding breaking changes

I know that @GabrielBarberini would be (or already is) specially interested in using such methods.
So I think we could discuss how to proceed with this before v1 release

[MateusStano]

What about the add_fin() method of the Rocket class? I think we should delete that one too. It does not work and is not used for anything

[Gui-FernandesBR]

What about the add_fin() method of the Rocket class? I think we should delete that one too. It does not work and is not used for anything

It's not documented tho.
Are you sure it doesn't work? This seem to be such an important feature

[MateusStano]

It's not documented tho.
Are you sure it doesn't work? This seem to be such an important feature

I have no clue if it works. It might run but I also would have no clue if what it does is even correct

I've never seen it being used, and as far as I know, it was never finished

[Gui-FernandesBR]

It's not documented tho.
Are you sure it doesn't work? This seem to be such an important feature

I have no clue if it works. It might run but I also would have no clue if what it does is even correct

I've never seen it being used, and as far as I know, it was never finished

Yes I agree removing it then. I just read it and there's no sense for that method to be defined inside the Rocket.py file.
We should resolve this in AeroSurface.py

I'm still waiting for a review here, so I can fix all the review comments at the same time.

[MateusStano]

I understand why these functions are @static_methods and I think this is fine as is, but just for the sake of questioning

Why are these function @static_methods and not functions in utilities.py?

[Gui-FernandesBR]

Good question!

1- They are used inside other RocketPy classes, so there's no possibility

2- one could suggest to store these methods in tools.py tho. However, I think they are quite related to the Environment class, so it makes more sense if they stay here at this file, together with similar methods. As another example, you can see the reshape_thrust_curve method of the motor class. But this is just a matter of preference tho.

[MateusStano]

Everything seems good here. I couldn't find anything else that needed deprecation in the code. Just needs to remove add_fin and its ready to go