Repository navigation
Publish mssql-python as a conda-forge package #563
Description
Activity
Hi Martin Studer (@martinstuder), 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!
Hello Martin Studer (@martinstuder)
Thanks for your suggestions.
Publishing mssql-python on Conda package manager is on our roadmap and the work on it will start this month. Please stay tuned and we will update this space once we are ready to publish the package on Conda.
Sumit
Sumit Sarabhai (@sumitmsft) any progress on this?
A concrete data point for this request: I'm on RHEL 9, managing a conda env using pixi (and installing this lib via pypi-dependencies), some of the changes around splitting out the odbc driver now make this more challenging. The pip wheel fails to load in conda environments that contain conda-forge krb5 (which is common — libcurl, pyarrow etc. pull it in transitively).
With mssql-python 1.13.0, connecting fails with the generic DDBC Error: Failed to load the driver. The underlying dlopen error is:
OSError: /lib64/libkrb5.so.3: undefined symbol: krb5int_push_fscreatecon_for, version krb5support_0_MIT
The driver expects the system krb5, but in a conda env the loader ends up mixing system and conda-forge krb5 libraries in the same process, and the two aren't symbol-compatible. Whether it breaks depends on which krb5 the env happens to contain, so it comes and goes with unrelated lockfile changes.
Current workarounds: LD_LIBRARY_PATH=$CONDA_PREFIX/lib, or preloading the conda krb5 libs with ctypes.CDLL(..., RTLD_GLOBAL) before importing mssql_python. Neither is something we'd want to ship.
Two notes for whoever picks this up:
- The conda-forge build would need the native driver linked against conda-forge krb5/OpenSSL with conda rpaths. A grayskull-style repackage of the wheel would carry the same system linkage and fail the same way. Since the
driver now ships separately as mssql-python-odbc, it could become its own conda package. - Unrelated to conda: it would help a lot if the "Failed to load the driver" message included the dlopen error text — the raw OSError points straight at the cause.
- The conda-forge build would need the native driver linked against conda-forge krb5/OpenSSL with conda rpaths. A grayskull-style repackage of the wheel would carry the same system linkage and fail the same way. Since the
- added 4 commits that reference this issue
on Aug 14, 2026 - added a commit that references this issue
on Aug 31, 2026 - added a commit that references this issue
on Sep 2, 2026
Is your feature request related to a problem? Please describe.
Many data science and machine learning workflows rely on conda as the primary package and environment manager. Currently, mssql-python is only available via PyPI, which creates friction for conda-based projects. When a project's dependency tree is managed through conda (e.g. using conda-forge), mixing pip-installed packages can cause environment inconsistencies, dependency conflicts, and reproducibility issues - particularly in regulated or enterprise environments where environment lockfiles and auditable builds are required.
Describe the solution you'd like
It would be great if mssql-python would be available as a conda package on the conda-forge channel (or an alternative channel). This would allow users to install it via
conda install -c conda-forge mssql-python. This involves submitting a feedstock recipe to the conda-forge/staged-recipes repository. The recipe would define the package metadata, source (pointing to the PyPI release or source tarball), build requirements, and runtime dependencies - following the standard conda-forge contribution process. Ideally the conda package would be kept in sync with PyPI releases so that both channels remain up to date.Describe alternatives you've considered
Additional context
The conda-forge contribution process is well-documented and community-supported. The grayskull tool can auto-generate an initial feedstock recipe directly from the PyPI package metadata, which significantly reduces the effort required: grayskull pypi mssql-python. Many comparable database drivers (e.g. pyodbc, psycopg2) are already available on conda-forge.