chore: revert to original pip licenses

[moe-ad]

Closes #1047.

I ran tests in the Metapackage against Python 3.9 through 3.13 and the tests pass (see ansys/pyansys#1205).

Since pip-licenses officially supports Python 3.9, should we still be enforcing 3.10 as the minimum Python in ansys/check-licenses or it is ok to stop doing that like I have already done?
@RobPasMue @SMoraisAnsys @jorgepiloto

[SMoraisAnsys]

I would keep the minimum value to 3.10.

@moe-ad Could you also have a look into https://github.com/stefan6419846/pip-licenses-lib and https://github.com/stefan6419846/pip-licenses-cli ? They seem to be a solution that got created while, or even before that, the original pip-licenses repo was unmaintained. The situation has changed but it would be great to know how more reliable one repo would be over the other.

[SMoraisAnsys]

Thanks for the changes @moe-ad It seems that the repo is indeed back alive and that the changes performed aren't sketchy. Could you have a look at my comment ?

[moe-ad]

@SMoraisAnsys I added c9b95da. Can you please have one final look before I merge?

[RobPasMue]

Since pip-licenses officially supports Python 3.9, should we still be enforcing 3.10 as the minimum Python in ansys/check-licenses or it is ok to stop doing that like I have already done?

Python 3.9 is at EOL. We shouldn't allow running it anyway.

[SMoraisAnsys]

Proposed changes to leverage the requirements.txt file that you added :D

[RobPasMue]

FYI @moe-ad, for next time - it's nice to credit reviewers with their suggestions 😄 if possible, when addressing a PR review, handle the suggestions provided through the built-in mechanism that GitHub's web UI provides you. That way commits are co-authored. You can apply them in batch mode as well

Unless it really implies other major refactorings, it's typically a best practice.

[RobPasMue]

LGTM! Thanks for the contrib!

[RobPasMue]

I've got my doubts about a change

[moe-ad]

Proposed changes to leverage the requirements.txt file that you added :D

How could I have missed that. Thanks @SMoraisAnsys and @RobPasMue.

FYI @moe-ad, for next time - it's nice to credit reviewers with their suggestions 😄 if possible, when addressing a PR review, handle the suggestions provided through the built-in mechanism that GitHub's web UI provides you. That way commits are co-authored. You can apply them in batch mode as well

Unless it really implies other major refactorings, it's typically a best practice.

@RobPasMue I usually do that. But between Sebastien's suggestion missing -r and needing to update other parts of the file, I just one-shotted it via local commit (PS: I didn't see that you also made a suggestion before doing that).

[SMoraisAnsys]

Thanks for the changes @moe-ad, LGTM :)

[RobPasMue]

I usually do that. But between Sebastien's suggestion missing -r and needing to update other parts of the file, I just one-shotted it via local commit (PS: I didn't see that you also made a suggestion before doing that).

All good, no worries - and thanks for the changes @moe-ad ! I learned something new as well. I thought the pip upgrade had to always be done on a separate step (to avoid messing with the rest of the pip installs in fact)!