D335: Open sourcing process: use ansys-api-edb

[SMoraisAnsys]

This PR includes changes to move into public. The most relevant one is the use of the ansys-api-edb package.

Changes:

• remove proto files and use ansys-api-edb
• update build dependencies to match ansys-api-edb
• update project name and description
• remove python3.7 from ci_cd.yml, tox.ini and README.rst
• refact architecture to add core directory
• update licence year
• remove requirements files
• add optional dependencies (notebook, tests, doc) in pyproject.toml file and update README.rst, tox.ini and ci_cd.yml accordingly
• use PIP_EXTRA_INDEX_URL to leverage private pypi (where ansys-api-edb is available)
• change project extra deps to be compatible with private pypi

[hiro727]

if the idea is to discorage users from using directly, I would prefer ansys.edb.core.internal @drewm102 any thoughts?

[drewm102]

@hiro727 @SMoraisAnsys Yes, I agree. I think using ansys.edb.core.internal would be best.

[SMoraisAnsys]

I didn't do it to discourage users from using it. It's just a pattern used in other pyansys projects https://github.com/ansys/pymapdl/tree/main/src/ansys/mapdl/core, https://github.com/ansys/pyansys-geometry/tree/main/src/ansys/geometry/core, https://github.com/ansys/pyfluent/tree/main/src/ansys/fluent/core.
It should help to leverage common github action (if none exist atm, they might appear later on) and simplify common project maintenance.

[hiro727]

how would this work in case of:

1. before ansys-api-edb is published on pypi
2. when working on local changes made to ansys-api-edb

[SMoraisAnsys]

Good point. As stated in the PR note, this has side effects for the moment since ansys-api-edb is not yet public.
Collaborators will need to have access to ansys-api-edb. Here are cases I have in mind:

• Users have to get access to ansys-api-edb. Once access is granted, they have to clone the repo locally and install it locally. Then, the installation of pyedb-core is not a problem.
• Developpers also need to have access to ansys-api-edb. If you want to work on local changes of ansys-api-edb, you'll have to trigger pip install /path/to/ansys-api-edb yourself since AFAIK flit does not support specifying local dependencies. I think we could try to use poetry because, from my knowledge, this package would let us use local dependencies .Now, if you want to test pyedb-core, you can use your previous workflow (based on tox). There is a pip install step for tests, doc and notebooks. It might even be possible to modify the tox.ini file to make it work with :

[testenv]
deps =
    -e /path/to/your/local/ansys-api-edb
install_command =
...

• To use the CI, a temporary tar ball of ansys-api-edb could be uploaded there and used until the package gets public.

What are your thoughts on this ?

[hiro727]

depends on the timeline to get ansys-api-edb published. broken unit tests would not be a big deal atm but broken doc build might pose some challenge in testing/getting documentation certified.

one option would be to include ansys-api-edb as a submodule to this repo then ci can build api as part of this build process (including when local changes are made to api repo)

if that is not ideal, maybe we could post a release asset of api and download it from here during ci runs as you mentioned

[SMoraisAnsys]

The CI should be fixed with a7f1a00
Could you please update the PR title to match your naming style ? This should make the PR pass the whole CI !

[SMoraisAnsys]

Closes #335