CHORE: Setting up ruff

[ecoussoux-ansys]

This PR corresponds to the first step towards using ruff for linting and formatting in the pyedb project, as described in #1237.
As such, completion of this PR should not result in closing #1237.
The present changes aim at providing pyedb with a similar basic ruff configuration as the one implemented for pyaedt in ansys/pyaedt#6157, removing isort, black and flake8 at the same time.

It should be noted that ruff does not replace the following tools, whose use in the project is therefore not affected by the changes introduced here:

• blacken-docs (used for formatting Python code blocks in documentation files): ruff does not support formatting/linting of embedded code (particularly in .rst or .md files). Similarly, blacken-docs does not support the ruff formatter as an alternative for black. This tool is therefore retained (as a pre-commit hook), despite the remaining dependency on black,
• codespell (fixes common misspellings in source code and other files), which is not integrated into ruff,
• numpydoc (used for formatting docstrings), which is also not integrated into ruff.

The changes in this PR are limited to the definition of a minimal configuration for ruff (in the pyproject.toml file) with only a small set of rules (namely "I"(sort) rules) applied to the code base, together with the introduction of pre-commit hooks for linting and formatting with ruff. Python files fixed by ruff are updated. Configurations for isort, black and flake8 are removed and the associated pre-commit hooks are also dropped.
The currently ignored rules (exhaustive list provided) shall be gradually applied to the project in subsequent PRs.

It is also worth mentioning that the list of rules selected until now for linting in the .flake8 file is not regarded as a reference for defining the implemented ruff configuration. Instead, this config is based on the recommendations from the pyansys-dev-guide, as introduced in ansys/pyansys-dev-guide#592.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 15.00000% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 49.56%. Comparing base (c43278e) to head (fe98f27).

❌ Your patch status has failed because the patch coverage (15.00%) is below the target coverage (85.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1233      +/-   ##
==========================================
+ Coverage   49.50%   49.56%   +0.05%     
==========================================
  Files         254      254              
  Lines       37900    37857      -43     
==========================================
- Hits        18764    18763       -1     
+ Misses      19136    19094      -42     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[svandenb-dev]

LGTM

[ecoussoux-ansys]

@svandenb-dev,
In my last commit I ran ruff linting and formatting against all the files again, which lead to some changes to enforce the I001 unsorted-imports rule that is part of the minimal config introduced for the tool.
I also added two entries to the list of the ignored rules for ruff in the pyproject.toml file (E712 true-false-comparison and N816 mixed-case-variable-in-global-scope).
On top of that, I updated the .pre-commit-config.yaml file to use the latest releases available for the ruff and blacken-docs hooks, also removing again the isort and flake8 hooks which were probably reintroduced when merging the main branch inside this one.
Hopefully these updates make the PR truly up-to-date and ready for review!

[SMoraisAnsys]

I think there should be some rewrite here to avoid the following changes from

nets.generate_extended_nets(
    resistor_below=5,
    ...
)

to

nets.generate_extended_nets(
    resistor_below = (5,)
    ...
)

>>> nets.generate_extended_nets(
>>> resistor_below=5,
>>> resistor_below = (5,)
>>>inductor_below=0.5,
>>> capacitor_above=0.1
>>> capacitor_above = 0.1
>>> )

It is even more strange with >>> power_nets=["VDD_CPU", "VDD_MEM"], to >>> power_nets = (["VDD_CPU", "VDD_MEM"],).

@ecoussoux-ansys Could you have a look ? I think it complexifies the documentation

[ecoussoux-ansys]

I think there should be some rewrite here to avoid the following changes from

nets.generate_extended_nets(
    resistor_below=5,
    ...
)

to

nets.generate_extended_nets(
    resistor_below = (5,)
    ...
)

>>> nets.generate_extended_nets(
>>> resistor_below=5,
>>> resistor_below = (5,)
>>>inductor_below=0.5,
>>> capacitor_above=0.1
>>> capacitor_above = 0.1
>>> )

It is even more strange with >>> power_nets=["VDD_CPU", "VDD_MEM"], to >>> power_nets = (["VDD_CPU", "VDD_MEM"],).

@ecoussoux-ansys Could you have a look ? I think it complexifies the documentation

Thank you for pointing this out. Indeed, this type of reformatting, which occurred in several places, is incorrect.

This happens because ruff is confused by the fact that in some doc strings, code examples that were spread over several lines did not have the >>> properly replaced by ... where needed.
When the correct syntax was in place, the reformatting of code examples in doc strings was performed as expected, as can be seen, for example, in the changes introduced in src/pyedb/dotnet/database/components.py! However, when a line begins with >>> when it should begin with ..., ruff considers it to be an independent statement and does not interpret the comma at the end of the line as a separator between consecutive function arguments, but as the syntax for defining a tuple, which ruff makes explicit by introducing parentheses.

All occurrences of this kind of reformatting should be corrected by the changes introduced by c881dac.