Python 3.11 is only supported python version

[psschwei]

Summary

Only build and test against python 3.11

Details and comments

Removes changes made in #1034

[psschwei]

We have a whole mechanism to allow users to choose their Python version that will also need to be ripped out

[Tansito]

We have a whole mechanism to allow users to choose their Python version that will also need to be ripped out

Good catch, thinking in this feature... Probably we could remove the config by now from the client and in the api use always the same image node_image = settings.RAY_NODE_IMAGE. With the providers I don't think it has sense to allow this kind of configuration from the user, wdyt? 🤔

[Tansito]

Sorry Paul, missclick 😅

[psschwei]

test failures should be resolved by 1b3e8ee , so let's get the UBI PR merged first then return to this one

[psschwei]

let's get the UBI PR merged first then return to this one

UBI PR merged, so let's see if we're in business 🤞

[psschwei]

This also drops the number of gh actions we run to 10 (down from 18)

[akihikokuroda]

With the providers I don't think it has sense to allow this kind of configuration from the user, wdyt?

It maybe too late but it may be useful for the preparation for the next python version update. The provider can test their function with the new python version in advance.

[akihikokuroda]

Is this still necessary?

[psschwei]

nope

[psschwei]

The provider can test their function with the new python version in advance.

Good point. Maybe when the project stabilizes we'll need to start cutting release candidates (similar to what qiskit does) for users to test new versions?

[akihikokuroda]

Can we take this python_version out, too?

[psschwei]

I wasn't sure if we needed that for legacy data, but can try taking it out.

[Tansito]

Not needed. In fact we didn't move data from our old database to the new one in the migration what it simplifies even more this.

[Tansito]

What we are going to need to test it's if somethings breaks if old data exists in the database. I can help with that test later.

[Tansito]

The provider can test their function with the new python version in advance.

Yep, I didn't think about this but it's a good point for the future, Aki. I agree, let's do the next:

• Let's keep the configuration by now (I liked the idea of the releases candidates)
• Let's remove python 3.9 and 3.10 support only
• Let's maintain the -py311

Thank you guys! 🙏

[psschwei]

I'd still drop the python version. Testing against a release candidate shouldn't be exposed publicly, instead we'd set it up on a staging environment and run tests against that explicitly. Plus, if we're making this available for providers only then we'd need to wrap some kind of permissions around that field so that only providers could call it. Much simpler to just drop it completely.

[Tansito]

@psschwei changes look good, if you remove python_version from the model I can help to test it 👍

[Tansito]

And after reading you correctly, I agree. Let's see in future discussions how can we improve that way to facilitate the access to the providers to these nightlies versions.

[psschwei]

@akihikokuroda @Tansito I think I've got the last bits of python_version out now, so this one is ready for another look

[Tansito]

@psschwei can we regenerate the migrations to have only one migration? For the rest of the things I see everything fine. I added @IceKhan13 too to the PR for his awareness 😄

I continue discussing with myself if this approach has sense in our context or not. But I don't see a way where we can support more than one python version without dying in the effort at this moment.

[Tansito]

LGTM Paul, thank you! I would like to know if @akihikokuroda and @IceKhan13 agrees with the change too

[Tansito]

Btw @psschwei I think I added you some conflicts due to my merge 😅

[Tansito]

@psschwei feel free to merge it so I can update #1416 and we merge both PRs today 💪