-
Notifications
You must be signed in to change notification settings - Fork 561
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
Fix the package versions in the CI-generated wheels #1121
Fix the package versions in the CI-generated wheels #1121
Conversation
Just to emphasize, once this PR is merged, we should be able to let
|
..or else PyPi will reject them: Binary wheel 'pyodbc-4.0.35-cp36-cp36m-linux_x86_64.whl' has an unsupported platform tag 'linux_x86_64' If repairing, must "exclude" all the .so files from the wheel so they don't interfere with any existing installations.
FYI, I've uploaded a deployment based on this branch to the Test PyPi index, here: All the wheels were generated by the CI pipelines. Feel free to try installing them at your leisure: Note, the linux wheels do not include any |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job, Keith! Good catch on the PiPI naming thing.
Wheels from the PyPI test site install just fine under Py3.11 on Windows and Py3.10 on Ubuntu 22.04. As expected, pyodbc won't run unless unixODBC is installed on Linux (verifying that the .so files are not bundled in the wheel).
So +1 from me!
ping @mkleehammer re: this and #1096
Thanks, Gord. I too have checked the install works from the Test PyPi on Windows 64-bit (Python 2.7, 3.6-3.11), Linux Ubuntu 20.04 (Python 3.10), and Mac (not ARM) (Python 3.8). I'll merge this PR now to get it in the master branch, but if we need to make changes subject to review by Kleehammer, that will be easy enough. It'll be great to drop Python 2.7 at some point but it'll be even better to fix the Linux wheels through version 4.0.35 in the meantime. |
Further to this PR, here are my thoughts on how a new release should be deployed. Happy to hear any feedback on this. Maybe add this to the Wiki?
|
The wheels generated by
cibuildwheel
in our CI pipeline currently have the wrong pyodbc package version id.s For example, the file "pyodbc-4.0.dev0-cp310-cp310-win_amd64.whl". "4.0.dev0" is incorrect and should be something like "4.0.35". The wheels are given the id "4.0.dev0" becausesetup.py
is unable to find any tags in the available git repo. When building pyodbc locally on laptops,setup.py
usually figures out the version from the git tags in the local repo.setup.py
is unable to figure this out in the CI pipeline because Github Actions does not include the tags when it fetches the repo. It uses a command similar to:Note the options
--no-tags
and--depth=1
.To get around this, I have introduced a constant to
setup.py
called VERSION, currently of value "4.0.35". Whensetup.py
is called within the CI pipelines,setup.py
will detect this and use the VERSION constant. This constant will naturally have to be manually maintained but that shouldn't be too onerous.Whilst here, I have added a basic
pyproject.toml
file to help pyodbc be more PEP517-compliant. We should probably make more use ofpyproject.toml
in the future, transferring the static elements ofsetup.py
into it at some point.Also, a tweak to
.gitignore
.