PyPI publish - Githubissues

mmacata commented 2 years ago

This PR adresses #370

it prepares to publish actinia-core on pypi
it adds CI to publish on release
it is not needed to specify the actinia-api version in different Dockerfiles. It is only needed to specify the version in pyproject.toml
the actinia-core version must now be specified in the pyproject.toml as well and is not read out of the github release version anymore. A github workflow exists to take care of automated update on a release.
Some python scripts were moved
One python script was moved and renamed, deprecation warning added:
- rq_custom_worker can now simply be called with actinia-worker

TODOs:

~~the hard version pinning is not best practise, but won't work otherwise due to dependency conflicts like #345~~
~~clear duplicate config in setup.py, setup.cfg and pyproject.toml~~
~~fix PyPI upload issues (ERROR HTTPError: 400 Bad Request from https://test.pypi.org/legacy/ Invalid value for requires_dist. Error: Can't have direct dependency: 'actinia-api @ https://github.com/mundialis/actinia-api/releases/download/3.2.0/actinia_api-3.2.0-py3-none-any.whl')~~
~~add GHA~~
publish plugins also on pypi to use them as dependencies -> https://github.com/actinia-org/actinia-docker/issues/23
remove requirements.txt after a while when most builds have been adjusted

mmacata commented 1 year ago

Added github actions to auto-update version in pyproject.toml. https://test.pypi.org/project/actinia-core 4.8.1 is somehow broken... pip install -i https://test.pypi.org/simple/ actinia-core

mmacata commented 1 year ago

Workflows were tested via mmacata fork - I created a release there to test the publishing to pypi and the version update in pyproject.toml. pip3 install actinia-core was successful. I now deleted the resource again to not interfere with this actinia-org remote.

One question is left to @neteler and @anikaweinmann : In this PR I suggest to rename some scripts, e.g. rq_custom_worker can now simply be called with actinia-worker but also actinia_user -> actinia-user. I thought this is a good idea as we renamed actinia_core in general to actinia-core. But would it be an API breaking change? Do you think it is a good idea, especially as we have actinia_user in all start.sh scripts?

anikaweinmann commented 1 year ago

Workflows were tested via mmacata fork - I created a release there to test the publishing to pypi and the version update in pyproject.toml. pip3 install actinia-core was successful. I now deleted the resource again to not interfere with this actinia-org remote.

One question is left to @neteler and @anikaweinmann : In this PR I suggest to rename some scripts, e.g. rq_custom_worker can now simply be called with actinia-worker but also actinia_user -> actinia-user. I thought this is a good idea as we renamed actinia_core in general to actinia-core. But would it be an API breaking change? Do you think it is a good idea, especially as we have actinia_user in all start.sh scripts?

I think it is in general a good idea. Can we do it like other libraries and have first both actinia_user and actinia-user and actinia_user prints a warning, that it will be depricated soon?

mmacata commented 1 year ago

Workflows were tested via mmacata fork - I created a release there to test the publishing to pypi and the version update in pyproject.toml. pip3 install actinia-core was successful. I now deleted the resource again to not interfere with this actinia-org remote. One question is left to @neteler and @anikaweinmann : In this PR I suggest to rename some scripts, e.g. rq_custom_worker can now simply be called with actinia-worker but also actinia_user -> actinia-user. I thought this is a good idea as we renamed actinia_core in general to actinia-core. But would it be an API breaking change? Do you think it is a good idea, especially as we have actinia_user in all start.sh scripts?

I think it is in general a good idea. Can we do it like other libraries and have first both actinia_user and actinia-user and actinia_user prints a warning, that it will be depricated soon?

Yes I added this. It now looks like this:

/src/actinia_core # actinia-user list
[2023-05-09 14:57:58,717] INFO      : actinia-core.logging_interface -Log level is set to 'INFO' [in /usr/lib/python3.9/site-packages/actinia_core/core/logging_interface.py:254]
[b'actinia-gdi']
['actinia-gdi']
/src/actinia_core # actinia_user list
[2023-05-09 14:58:06,922] INFO      : actinia-core.logging_interface -Log level is set to 'INFO' [in /usr/lib/python3.9/site-packages/actinia_core/core/logging_interface.py:254]
[2023-05-09 14:58:06,927] WARNING   : actinia-core.actinia_user -The call "actinia_user" is deprecated and will be removed soon. User "actinia-user" instead! [in /usr/lib/python3.9/site-packages/actinia_core/cli/actinia_user.py:143]
[b'actinia-gdi]
['actinia-gdi']

neteler commented 1 year ago

Cool! :-) Just nitpicking: may I suggest "command" rather than "call" since it is on command line (?) in https://github.com/actinia-org/actinia-core/pull/373/commits/38944000cf6f6973d826671cb4b6aa1e4e4ab7c2#diff-26f6ed23fc8ccf9f2532e41ffac1f25448937225ec0f973e23d6921a3da072b8R56

mmacata commented 1 year ago

Workflows were tested via mmacata fork - I created a release there to test the publishing to pypi and the version update in pyproject.toml. pip3 install actinia-core was successful. I now deleted the resource again to not interfere with this actinia-org remote. One question is left to @neteler and @anikaweinmann : In this PR I suggest to rename some scripts, e.g. rq_custom_worker can now simply be called with actinia-worker but also actinia_user -> actinia-user. I thought this is a good idea as we renamed actinia_core in general to actinia-core. But would it be an API breaking change? Do you think it is a good idea, especially as we have actinia_user in all start.sh scripts?

I think it is in general a good idea. Can we do it like other libraries and have first both actinia_user and actinia-user and actinia_user prints a warning, that it will be depricated soon?

Yes I added this. It now looks like this:
/src/actinia_core # actinia-user list
[2023-05-09 14:57:58,717] INFO      : actinia-core.logging_interface -Log level is set to 'INFO' [in /usr/lib/python3.9/site-packages/actinia_core/core/logging_interface.py:254]
[b'actinia-gdi']
['actinia-gdi']
/src/actinia_core # actinia_user list
[2023-05-09 14:58:06,922] INFO      : actinia-core.logging_interface -Log level is set to 'INFO' [in /usr/lib/python3.9/site-packages/actinia_core/core/logging_interface.py:254]
[2023-05-09 14:58:06,927] WARNING   : actinia-core.actinia_user -The call "actinia_user" is deprecated and will be removed soon. User "actinia-user" instead! [in /usr/lib/python3.9/site-packages/actinia_core/cli/actinia_user.py:143]
[b'actinia-gdi]
['actinia-gdi']

I oversaw that I renamed the files and the commands didn't change for 3/4 of them :see_no_evil: Definitely not good working such a long time on one PR :upside_down_face: I will undo the warnings for all except rq_custom_worker.

As this is not widely used up to now - do you still see the need to do a major version increase @anikaweinmann ?

mmacata commented 1 year ago

Workflows were tested via mmacata fork - I created a release there to test the publishing to pypi and the version update in pyproject.toml. pip3 install actinia-core was successful. I now deleted the resource again to not interfere with this actinia-org remote. One question is left to @neteler and @anikaweinmann : In this PR I suggest to rename some scripts, e.g. rq_custom_worker can now simply be called with actinia-worker but also actinia_user -> actinia-user. I thought this is a good idea as we renamed actinia_core in general to actinia-core. But would it be an API breaking change? Do you think it is a good idea, especially as we have actinia_user in all start.sh scripts?

I think it is in general a good idea. Can we do it like other libraries and have first both actinia_user and actinia-user and actinia_user prints a warning, that it will be depricated soon?

Yes I added this. It now looks like this:
/src/actinia_core # actinia-user list
[2023-05-09 14:57:58,717] INFO      : actinia-core.logging_interface -Log level is set to 'INFO' [in /usr/lib/python3.9/site-packages/actinia_core/core/logging_interface.py:254]
[b'actinia-gdi']
['actinia-gdi']
/src/actinia_core # actinia_user list
[2023-05-09 14:58:06,922] INFO      : actinia-core.logging_interface -Log level is set to 'INFO' [in /usr/lib/python3.9/site-packages/actinia_core/core/logging_interface.py:254]
[2023-05-09 14:58:06,927] WARNING   : actinia-core.actinia_user -The call "actinia_user" is deprecated and will be removed soon. User "actinia-user" instead! [in /usr/lib/python3.9/site-packages/actinia_core/cli/actinia_user.py:143]
[b'actinia-gdi]
['actinia-gdi']

I oversaw that I renamed the files and the commands didn't change for 3/4 of them :see_no_evil: Definitely not good working such a long time on one PR :upside_down_face: I will undo the warnings for all except rq_custom_worker.

As this is not widely used up to now - do you still see the need to do a major version increase @anikaweinmann ?

actinia-org / actinia-core

PyPI publish #373