cucumber
python: Use Poetry to build and release
🤔 What's the problem you've observed?
Currently we use Poetry to make Python releases. However the current python implementation does not use Poetry.
✨ Do you have a proposal for making it better?
Use Poetry as the build system like we do in Cucumber Expressions.
@jsa34 could you help with this one?
With pleasure! I'll have a look in the next few days.
To note, we may have a problem supporting Python 2 if we use poetry as the latest Poetry version doesn't look like it supports Python 2. I believe this was an issue previously when I was considering dropping support for Python 2 in Cucumber modules.
Cheers! Much appreciated.
I don't see a problem with dropping support for Python 2. It was sunset in 2020 and we are running into issues with 3.11 where Python 2 features are being removed (e.g. https://github.com/cucumber/gherkin/issues/7).
Agreed, however, when I attempted to make the minimum supported version 3.x a few months ago, @brasmusson believed supporting Python 2.7 is important:
I view gherkin as a base library intended to be integrated and used in may different products and contexts. For such libraries wide compatibility support is a valuable feature. So generally I think that support for old version should be kept until it is to costly to keep them, rather than drop it as soon as the minimum supporter version is changed. I note that that Behave support 2.7 and >3.3 (https://github.com/behave/behave/blob/main/setup.py#L77). It is true that gherkin-python is not used in Behave, so it is not a blocker, but I do not seen the reason for gherkin-python to be more restrictive than Behave - which also provide gherkin parsing. setup.py python_requires=">=2.7, !=3.0., !=3.1., !=3.2.*",
Regardless, I will proceed to resurrect the python 3.x PR as a precondition to migrating to Poetry, if that's ok? I'll await to see if that's accepted (migrating to Python 3) before migrating to Poetry.
In the Slack Discussion the following condition was outlined:
However, I would opt for start feeling the pain before acting, rather than acting more speculatively.
I do reckon that we are starting to feel the pain right now. We could either invest time in creating a Github Action that works with setup.py to make a release or we can use Poetry which is known to work. So now would be the right time.
Looking at https://github.com/cucumber/common/pull/1982 I do see more changes then I like though. Would it be possible to first setup Poetry with only the minimal amount of changes?
To note, we may have a problem supporting Python 2 if we use poetry as the latest Poetry version doesn't look like it supports Python 2.
If Poetry is used for releasing and Poetry does cannot be executed on Python 2, the it means that when releasing Python 3 must be used. However that should not make it impossible for a user on Python 2 to use the released Gherkin package, as long as the classifiers for PyPi is setup appropriately.
I have made a stab at defining the Poetry files needed to be able to release with Poetry: https://github.com/cucumber/gherkin/pull/62
Thanks for this - things are a bit manic at work at the moment so haven't had a chance!
Looks good, but I'm not au fait with Python 2 in general (starting using Python a couple of years ago and never had a need to), but I was taking from the official docs: https://python-poetry.org/blog/announcing-poetry-1.2.0/#dropping-support-for-managing-python-27-projects
If there is a nice workaround, though, that's fab :)
FYI that distutils, which is currently used in setup.py is also slated for deprecation in python 3.12, so it will still work but needs to be removed
https://docs.python.org/3/whatsnew/3.10.html#distutils-deprecated
For swtiching: https://peps.python.org/pep-0632/#migration-advice
You can also swtich to setuptools and not use poetry for a lesser impact: https://setuptools.pypa.io/en/latest/build_meta.html
