-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't build with Python 3.12 #1855
Comments
I think SafeConfigParser was deprecated since moving away from Python 2 which BuildStream 2 does not support. As such, it could simply probably switch to plain ConfigParser. |
Exactly. I'll try to cook up a patch if I have a moment, but I'm not sure when I'll have time for it before next week. 😕 |
Tried patching
Building Buildstream in Fedora Rawhide (which does have Python 3.12) with that patch gave me the following :
At that point, I'm at a complete loss... I mean, I explicitly wrote in the code : |
Apologies for editing my comment earlier, I realised I had made a fool of myself and posted a wrong patch as well as wrong errors, which led me to a wrong conclusion. Should be all fixed now 😞 |
Above thing fails because you have ConfigParser instead of ConfigParser(). But as said, delete the entire SafeConfigParser code. There is no point in that backwards-compatibility branch. |
There is for Python < 3.12. And that will happen on all versions of Fedora except the latest (and not yet released?) 39. Remember that we build buildstream on multiple OSes, and all have to work. Ubuntu, Debian, etc... neither have Python 3.12 yet and won't have it for a while. Do you want to cut off Buildstream from all of those? |
Please no :) We support python back to the last non EOL version (that is currently either 3.7 or 3.8 I believe...). Do we intend to land this in BuildStream proper or land this in upstream versioneer first and then upgrade versioneer again ? PS: Long time no see Mathieu, hope you're doing well. |
This is not new API in Python 3.12. This is removing usage of API deprecated since Python 3.2. |
Unless a project supports Python2, this compat code is pointless. |
If the condition allowed supporting any Python version BuildStream 2 supports, I would not have proposed removing it. |
If the replacement used is available since 3.7 then we can remove the branch. 3.6 (EOL) support is almost impossible, I tried it and failed fast. |
Ah, I didn't know versioneer was imported into Buildstream as a subproject, I thought the code lived in Buildstream itself 🤷 So I guess the bug report needs to be opeed there then, I'll try to see if versioneer itself has the same problem on its own first. 😉
Now I am, not sure whether the others told you what happened to me or not? Long story short, in march 2020 I caught the flu. I didn't know, but turns out a possible consequence of any flu is always that it attacks your spinal chord and nervous system, which is exactly whet happened to me. 😞 Doctors told me while it's a known possible consequence, it's very serious and very rare, hurray for probabilities... So now I'm in a wheelchair, and I can't trust my body any more as it keeps sending me fake news. 🤦 Also I had to change my account as the Github support were unwilling to give me back access to Sorry for plumbing the ambiance 😄 |
@gtristan https://python.readthedocs.io/en/stable/whatsnew/3.2.html#configparser the change is documented here. It literally happened on 3.2. Like 10 versions of Python back in in 2011. You only should reference SafeConfigParser for Python 2 support. |
This read_file method was added in same release 12 years ago. |
Yeah that will be best (and maybe it will already be fixed there). To clarify; versioneer is a strange beast, as it does need to be vendored iirc, however while upgrading other things we've found ourselves needing to revendor it and update it.
Oh my, I'm so sorry to hear all of this. There aren't words for this. I had been wondering about your disappearance during the bst2 release days and didn't hear about any of this, I hope there is some path to recovery for you, and hope you are finding meaning and fulfillment in life, at least it's nice to see here you again ! |
To be fair, it looks like this is not the right way to integrate versioneer anymore either. https://github.com/python-versioneer/python-versioneer |
Given this, I would consider just making the simple solution which works on 3.2-3.12 and concentrate on changing versioneer integration separately. The project seems to have changed so that it won't be a simple copy-paste matter. |
OK, so modifying my patch to use Thank you @nanonyme, that should have been obvious, I guess the flu also destroyed this 😕 I'll open the same issue against versioneer then 😉 |
Another idea: setuptools-scm seems to be the recommended way to do this with recent python. Maybe we should consider looking into it? |
Bugs in setuptools-scm was the reason why we initially switched to versioneer:
I think we no longer really support developer mode installs with |
Vendoring is still supported, though the discussion above about ConfigParser/SafeConfigParser was already addressed. See my reply in the upstream ticket python-versioneer/python-versioneer#375 (comment) |
@Callek thanks for clarification. The fact that vendored versioneer apparently hasn't been updated for six years does though imply something in process needs to change. |
Looks like in fact versioneer dropped Python 3.6 support back in 2022 |
Python 3.6 afaik is EOL and near impossible to support for us.
When I updated versioneer earlier this year feb4940, I recall trying the non-vendored approach, and maybe this is still incomplete, it's somewhat of an unclear disaster involving python projects generally moving to python build and |
Yes, I just mentioned for completeness because you were commenting about this earlier. |
Something does not make sense here. Upstream said we have 0.18 vendored which is six years old. How is it possible you updated earlier this year? Did you update to wrong thing? |
The commit above updates it from 0.18 to 0.28, but it's only in master, not in any released version. |
@abderrahim the file in master still has this bug so I'm still confused. |
I may have created a frankeneer with my last update. My commit did replace the generated file at Indeed... and so it looks like I had taken the I should also say that... The toplevel Other than this, the version needs to be known in order to call So, maybe the right way is to |
First time around we were using `versioneer install --no-vendor`, and neglecting to remove the `versioneer.py` file from the toplevel, which is still required by BuildStream's setup.py for a few reasons. Instead, go back to `versioneer install --vendor` and update versioneer files correctly. Fixes #1855
Not sure if this will pass CI correctly, but tried it locally with This uses the supported (note that as far as config parsing goes, |
First time around we were using `versioneer install --no-vendor`, and neglecting to remove the `versioneer.py` file from the toplevel, which is still required by BuildStream's setup.py for a few reasons. Instead, go back to `versioneer install --vendor` and update versioneer files correctly. Fixes #1855
This is in line with what @Callek said earlier so I'm satisfied with that. |
Very cool. Can we have a release so I can update the Fedora package to it and see how it fails to build in Rawhide ? 😜 Or how can I make a release myself to try it out ? 🤔 |
I mean to propose a release very soon (with apache we now have a release voting process yay...), just want to get #1862 in there first... |
I strongly suggest rolling a tarball yourself and testing with Rawhide while waiting for the release. In case it still will not work, it means another release behind voting process. |
Alright, I did just that. From the latest git master (with updated I tried to build the Rawhide package with that, but then that tarball doesn't contain the same tree as the official one. 😕 I tried to work around that, and then the build process failed because I hadn't added Then it failed because the Now the build fails like this:
That's weird... I wonder if that's not all a side effect of the fact I didn't create the tarball the right way... So before I continue, how was I supposed to create it ? 😄 |
This is now defined in In theory, https://docs.buildstream.build/2.0/main_install.html should be helpful here... if it's not, then let's try to keep it up to date :)
Aha, so this is strictly for building the docs - which we normally do in CI via In this specific case, it looks like this is due to buildstream core not being installed at the time we are building docs, a condition which is satisfied by running the docs build in tox. Possibly this can be worked around with buildstream built but not installed with some PYTHONPATH trickery, I haven't tried this. |
Well, that doc page tells me how to install buildstream (which I already knew how), but not how to generate a tarball 😅 |
So, buildstream still fails in Rawhide :
I find this in the buildstram source code So first, can you confirm this is the right package ? If so, I'll start searching for someone to maintain it 😉 |
Actually, it might be this one instead... pyroaring 😕 |
Latter looks correct |
commit cf7ff12 in master branch First time around we were using `versioneer install --no-vendor`, and neglecting to remove the `versioneer.py` file from the toplevel, which is still required by BuildStream's setup.py for a few reasons. Instead, go back to `versioneer install --vendor` and update versioneer files correctly. Fixes apache#1855
Buildstream can't build with Python 3.12.
Python 3.12 deprecated a few things, among which is
configparser.SafeConfigParser
.https://docs.python.org/3.12/whatsnew/3.12.html#removed
Pretty sure the
versioneer.py
script could instead say something like :The text was updated successfully, but these errors were encountered: