Have more specific built wheels? #632
Description
Is your feature request related to a problem? Please describe.
While you have documented on your blog[1] that packaging multiple so files for each architecture is using a lot of PyPi space, I would like to add another consideration.
Part of our build infrastructure checks that every shared object file which is part of any of our dependencies has all of its linking requirements met, i.e. it can find libcrypto.so.3 etc.
By including shared object files for all distributions this causes our builds to fail as the fallback odbc shared libraries for alpine etc, do not have their dependencies met because they are missing libc.musl etc.
Describe the solution you'd like
The built wheels for this package should contain only the DDBC driver itself if ODBC connectivity is required it should be provided by the user's environment as is the practice for pyodbc IMO.
Describe alternatives you've considered
The built wheels could just contain the SO's for the arch they are built for.
Again IMO these libraries should be provided by the user.
Additional context
I recognise this is a bit of a me issue but I'm sure I'm not the only person who is prevented from using this library for this reason.
Activity
github-actions commentedon Jun 11, 2026
Hi Sam Leonard (@sam-leonard-ct), thank you for opening this issue!
Our team will review it shortly. We aim to triage all new issues within 24-48 hours and get back to you.
If you have additional information to share, please feel free to update the issue.
Thank you for your patience!
sumitmsft commentedon Jul 6, 2026
Hello Sam Leonard (@sam-leonard-ct) Thanks for filing this, and for clearly explaining the impact on your build pipeline.
What you’re seeing is a consequence of a deliberate design choice in
mssql-python. One of the primary goals for this package is to provide as close to a single-line installation experience as possible for customers, with minimal manual setup and as few external prerequisites as possible. To support that experience, the wheel includes the native ODBC-related components needed for the environments we currently target, rather than requiring every user to separately install and configure those dependencies first.We understand the issue this creates in environments like yours, where build or compliance tooling inspects every shared object included in a dependency and expects all link requirements to be resolvable on the target system. In that kind of validation flow, bundled fallback libraries for other distributions can appear problematic even though they are not intended to be loaded in your runtime environment.
At this point, we are not planning to move to a model where the package ships only the core driver layer and requires customers to provide all ODBC/native dependencies themselves. While that approach may work better for some advanced deployment environments, it would move
mssql-pythonaway from one of its core design goals: making setup simple and reducing the prerequisite burden for the broadest set of customers. In practice, that would mean more manual installation steps, more platform-specific configuration, and a less predictable out-of-box experience.That said, your feedback is valid and useful. We do think there is room to keep improving the packaging approach, particularly in ODBC-related areas, but any such changes have to be balanced against the goal of preserving the simple installation experience that
mssql-pythonis designed to provide.Thanks again for raising this and for sharing the specific constraint from your infrastructure, it helps us evaluate where the current packaging approach creates friction.
sam-leonard-ct commentedon Jul 7, 2026
Would it be possible to publish a separate package/wheel without the fallback? something like mssql-python-bare.
It would add complexity to your build pipeline but would enable use in an environment like ours and it would preserve mssql-python's install simplicity.
sumitmsft commentedon Jul 16, 2026
Hi Sam Leonard (@sam-leonard-ct)
At this point we do not have plans for publish something like mssql-python-bare. But I take this point as a valid request. I understand its importance in certain enterprise environments. However, this might take sometime because we have to make changes to our pipelines and architecture. I can't give you a concrete ETA as of now, but added it to our backlog.
jahnvi480 commentedon Aug 13, 2026
Hi Sam Leonard (@sam-leonard-ct),
Good news on this one. Since we last spoke we've reworked how the ODBC driver binaries are packaged, and the change directly targets the problem you described.
Starting with v1.13.0, mssql-python no longer bundles the ODBC driver binaries in its own wheel. They now ship in a dedicated companion package, mssql-python-odbc, which mssql-python depends on and pip pulls in automatically — so the one-line pip install mssql-python experience is unchanged.
The key part for your build tooling: mssql-python-odbc is published as platform-specific wheels, and each wheel contains only that platform's driver binaries. pip resolves the single wheel matching your platform, so a glibc/manylinux install no longer carries the Alpine/musl fallback .so files (and vice-versa). Those cross-distro fallback libraries — the ones whose link requirements (libc.musl, etc.) couldn't be satisfied on your system — are simply not present anymore.
One clarification on the "provide ODBC yourself" idea: in the current design mssql-python loads the driver exclusively from mssql-python-odbc and does not fall back to a system-installed ODBC driver. So uninstalling mssql-python-odbc would make mssql-python fail to import rather than switch to your own driver. A fully bring-your-own-ODBC build (shipping just the driver layer, pyodbc-style) is still tracked on our backlog as a separate item.
Would you be able to try the v1.13.0 packaging and let us know whether the platform-specific split clears your build validation? If there's a remaining gap for your environment, we'd like to capture the specifics.
Thanks again for the detailed report.
sam-leonard-ct commentedon Aug 13, 2026
Thats super exciting thanks for letting me know! I will have another go at packaging this in our environment hopefully later today :D
sam-leonard-ct commentedon Sep 16, 2026
Sorry for the delay in getting back to you I've been incredibly busy both at work and outside of work.
Sadly this did not fix the packaging issue for us as our system is still searching for the musl-libc binary pulled in by the alpine side of the manylinux x86_64 package, it seems you also publish a musllinux package with the same contents? I'm going to open a new issue as this seems to be a bug in itself.