Python 3.11 Support

[Phillip Verheyden]

Hello, I am a user of gremlinpython and am also trying to use Python 3.11 across all of my projects, mainly because of the overall performance improvements.

The blocker that I currently have with gremlinpython is the pinned aiohttp dependency. The aiohttp version that gremlin is currently targeting is <=3.8.1. The first Python 3.11-supported version of aiohttp is 3.8.3.

It looks like this change has already been made to relax the aiohttp version restrictions in https://github.com/apache/tinkerpop/commit/8e356fc3c67bff462143bb7dab9899ba5aef06cf. My thought was that this was just going to be automatically available as part of the 3.6.2 release, but it appears that this didn't make the cut for 3.6.2. Here is some output of my dependency tree, a snippet of poetry show --tree:

gremlinpython 3.6.2 Gremlin-Python for Apache TinkerPop
├── aenum >=1.4.5,<4.0.0
├── aiohttp >=3.8.0,<=3.8.1
│   ├── aiosignal >=1.1.2
│   │   └── frozenlist >=1.1.0
│   ├── async-timeout >=4.0.0a3,<5.0

Any reason why this wasn't included in 3.6.2? Any way to have a short-order follow-up release with this relaxed dependency? Unfortunately Poetry is very specific about dependency versions so I don't have a way to override the version of aiohttp.

Appreciate the help!

[Cole Greer]

Hi,

I took a look into this and it looks like the PR where this commit was originally submitted was targeted for our master branch. To give some context, the master branch accumulates all changes which will eventually make up the next major release of tinkerpop (currently 3.7.0). Any changes intended for updates to existing major releases should go into the corresponding dev branch (ie. 3.5-dev). In general any changes merged into an earlier dev branch will also get merged forward into future dev branches. For example if a commit is added to 3.5-dev, it will also be merged into 3.6-dev and master so that this change will make it's way into the next releases in all of the 3.5.x, 3.6.x, and 3.7.x branches. In general any change which is non breaking should be made to target earliest actively maintained dev branch (currently 3.5-dev) in order to make it into all upcoming releases. I don't see anything in either the PR or the accompanying JIRA which gives any reason to withhold this change from either 3.5.x or 3.6.x. As long as this wouldn't create any noticeable change to any users of gremlin-python other than removing this restriction, I don't see as reason why this cannot go into the 3.5.x and 3.6.x branches.

As for the possibility to initiate a "lightning release" to get this change out quickly, I can't give a full answer on that. That decision would have to come from the tinkerpop PMC. I'm not aware of any historical precedent where tinkerpop has undergone such quick, rapid releases. I suspect that there would need to be substantial demand for such a change in order to trigger such a release but I'm really not the right person to answer that question. In terms of next steps, I would suggest opening a new issue which links to https://issues.apache.org/jira/browse/TINKERPOP-2810, and requests the version change be brought into the 3.5.x and 3.6.x version branches.

- Cole Greer

[Phillip Verheyden]

Thanks for the information Cole. Based on that, I went ahead and made a backport PR at https://github.com/apache/tinkerpop/pull/1958 to get this into the 3.6 line.