Closed KS-HTK closed 2 months ago
@SimonRubenDrauz, @mfranz13: This PR looks good to me, I think we should merge it soon. The only part that is still unclear to me is what pandapower version should be used in the tests (as @KS-HTK mentioned, it is not usual to install from develop, but that would mean less sync between pandapower and pandapipes). We should clarify that first.
@SimonRubenDrauz, @mfranz13: This PR looks good to me, I think we should merge it soon. The only part that is still unclear to me is what pandapower version should be used in the tests (as @KS-HTK mentioned, it is not usual to install from develop, but that would mean less sync between pandapower and pandapipes). We should clarify that first.
I did not change any test regarding the normal code base. What I changed is the explicit installation of pandapower master branch (release versions). There should never be a commit to pandapower master that is not also a release to pypi. So pip install pandapower
should result in the same state as installing it from the master branch. I only did this change in the docs_check pipeline. I did not take a closer look at any other pipelines. So this should also not affect any builds but only the testing of the Docs build. So nothing regarding the develop branch of pandapower was mentioned or changed here.
But to add to that mentiond descussion: In my oppinion tests should never be done against a develop version, the develop version should be regarded as unstable. And while it is not the goal it might occur that the develop version can not be installed. So no other projects should us it for testing of their own code. I also do not see a large issue with being one or two minor verison behind pandapower. But that is not for me to decide. In my oppinion a branch can exist that has been developed using the develop version of pandapower, but it should not be merged into the pandapipes develop branch until the required set of features is actually in the latest pandapower release. Otherwise it might occur that panadpipes may want to make a release but is forced to wait for pandapower because one would have a release that requires a develop version of pandapower. This would not be a great position to be in.
switched from setup.py to pyproject.toml
added change to CHANGELOG.rst version in init.py and doc/source/conf.py is now read from pyproject.toml removed content of setup.py removed calls to setup.py in workflows as calling setup.py directly is deprecated
This PR adds one new dependency. sphinx-pyproject This is to allow the conf.py to read values from the pyproject.toml so incrementing the version there is no longer a manual operation. I also changed the github workflows to not call setup.py as per this post.
Important:
build does not support zip format. So builds are now tar.gz this should not make a difference to users as it can be installed by pip either way. also I did not add back the sdist flag, as i do not see why it should not publish a whl on pypi. If this is not desired build can be forced to only build the tar.gz distribution.