Merge tooling config into pyproject

[rsnk96]

Description

This is a housekeeping MR, meant to simplify the project complexity at root. Tooling and CQ config files (bandit, py-codecoverage, pylint, mypy, pytest) have been moved into pyproject.toml, since it is becoming the standard way of defining all tooling-config in python (Ref: https://peps.python.org/pep-0621/)

NOTE: tox.ini has been left as-is, since it was larger, and probably can be addressed in a separate MR (so that this MR is simple to review). Additionally, flake8 config file has also been left as-is, as they have decided to not yet officially support pyprojecte

Status

Done, ready for review

Checklist (tick everything that applies)

• Code linting (required, can be done after the PR checks) (No code changes made)
• Documentation
• Tests (No functionality added)
• ICLA (required for bigger changes)

[Kami]

Thanks for this change 👍

I will go ahead and test it locally and if everything looks fine, merge it into trunk.

[Kami]

I tested it locally and everything except mypy change seems to be looking fine. I'll dig in why mypy config is not working as it should and hopefully fix it.

Eventually we can also move package metadata from setup.py into pyproject.toml.

[Kami]

I think 739d053 should do the trick for the MyPy config migration.

[Kami]

Needed two more small fixes for coverage and bandit (cd01296, a39b640), but everything appears to be working / passing now.

[codecov-commenter]

Codecov Report

Merging #1901 (a39b640) into trunk (d163f9b) will increase coverage by 0.01%.
Report is 49 commits behind head on trunk.
The diff coverage is 89.71%.

@@            Coverage Diff             @@
##            trunk    #1901      +/-   ##
==========================================
+ Coverage   83.11%   83.12%   +0.01%     
==========================================
  Files         353      353              
  Lines       81269    81317      +48     
  Branches     8587     8592       +5     
==========================================
+ Hits        67541    67588      +47     
- Misses      10922    10924       +2     
+ Partials     2806     2805       -1     

Files Changed	Coverage Δ
libcloud/backup/drivers/dimensiondata.py	94.94% <ø> (ø)
libcloud/common/aliyun.py	74.44% <ø> (ø)
libcloud/common/azure.py	86.30% <ø> (ø)
libcloud/common/azure_arm.py	73.02% <ø> (ø)
libcloud/common/durabledns.py	99.25% <ø> (ø)
libcloud/common/google.py	71.35% <ø> (ø)
libcloud/common/gridscale.py	83.93% <ø> (ø)
libcloud/common/kubernetes.py	80.81% <ø> (ø)
libcloud/common/nttcis.py	73.59% <ø> (ø)
libcloud/common/types.py	97.06% <ø> (ø)
... and 73 more

[Kami]

Merged into trunk. Thanks!

[rsnk96]

Glad to see it merged @Kami ! :)

Had two quick follow up queries, would appreciate it if you could help me out:

1. Do you think a vendor-neutral queue API would make sense here? (Ref: [RFC] Supporting Queues / Messaging Pipelines across Cloud Providers (Ex: AWS SQS) #1786). I started working on this merged housekeeping MR because I was looking to eventually contribute a queue API.
2. If I'm contributing more code here, any apache-project specific practices I've to be aware of, apart from signing the ICLA (my first apache project ;))?

[Kami]

@rsnk96

1. Yeah, I think it makes sense. But since queuing APIs are usually quite poll heavy, I think it also makes sense to expse async API in addition to the sync one.
2. ICLA is a good start. We have some project specific information here - https://libcloud.readthedocs.io/en/stable/development.html