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.
Links:
[1]: https://techcommunity.microsoft.com/blog/sqlserver/mssql-python-1-7-1-and-the-case-of-the-missing-megabytes/4521991
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.
Links:
[1]: https://techcommunity.microsoft.com/blog/sqlserver/mssql-python-1-7-1-and-the-case-of-the-missing-megabytes/4521991