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
- Using pip inside a conda environment: this is the current workaround, but it undermines the integrity of conda environment solves and is discouraged in environments where full conda-managed reproducibility is required.
- Self-hosting a conda package: it is possible to build a local conda package from the PyPI source using conda build. However, this places a maintenance burden on end-users and is not a scalable or shareable solution.
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.
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.