Feature Request: Publish Binaries to PyPI for Easy Installation and Dependency Management

[RovingStone]

Summary

Please consider publishing pre-built binaries of this project on PyPI. This would make installation much easier for users who do not work with Cargo directly, as they could simply use pip to install the package.

Benefits

• Ease of Use: Many Python developers are more familiar with pip and PyPI than with Cargo, and providing binaries on PyPI would streamline the installation process for them. There is a list of tools avaliable for installation via pip: clang-format, cmake, git-cliff, ninja etc.
• Developer Dependency Management: Publishing the binaries on PyPI would allow users to specify the package as a development dependency in pyproject.toml, integrating more easily with tools like poetry, uv and pip-tools.

Proposed Solution

• Build the binaries as part of the release process and upload them to PyPI.
• Update the documentation to provide installation instructions using pip.

Thank you for considering this enhancement to make the project more accessible!

[KeisukeYamashita]

Thank you for raising this issue!
I’ll give it some thought!

[Wrench56]

@RovingStone @KeisukeYamashita I do agree with making commitlint-rs available without cargo, but pip wouldn't make sense either. I think the best course of action is to upload the binary to winget or to provide an easily downloadable installation script (curl is generally on most machines even on Windows) that installs the binary from GitHub. Note, I'm on Windows, but I have access to a bash terminal (I'm not sure which one I have as default, but I'm pretty sure git comes with a bash terminal even on Windows) so I can use shellscripts. I came up with the following script:

#!/bin/sh

# Detect the architecture
ARCH=$(uname -m)
case $ARCH in
    x86_64)
        ARCH="x86_64"
        ;;
    arm64 | aarch64)
        ARCH="aarch64"
        ;;
    *)
        echo "Unsupported architecture: $ARCH"
        exit 1
        ;;
esac

# Detect the operating system
OS=$(uname -s)
case $OS in
    Darwin)
        OS="apple-darwin"
        ;;
    Linux)
        OS="unknown-linux-gnu"
        ;;
    MINGW* | MSYS* | CYGWIN* | Windows_NT)
        OS="pc-windows-msvc"
        ;;
    *)
        echo "Unsupported operating system: $OS"
        exit 1
        ;;
esac

VERSION="v0.2.2"
FILENAME="commitlint-${VERSION}-${ARCH}-${OS}.tar.gz"
BASE_URL="https://github.com/KeisukeYamashita/commitlint-rs/releases/download/${VERSION}"
DOWNLOAD_URL="${BASE_URL}/${FILENAME}"

# Download the TAR
echo "Detected system: $ARCH-$OS"
echo "Downloading: ${DOWNLOAD_URL}"
curl -L -o "${FILENAME}" "${DOWNLOAD_URL}" || { echo "Failed to download ${FILENAME}"; exit 1; }

# Verify the download
if [ -f "${FILENAME}" ]; then
    echo "Downloaded successfully: ${FILENAME}"
else
    echo "Error: File not downloaded"
    exit 1
fi

echo "Extracting: ${FILENAME}"
tar -xzf "${FILENAME}" || { echo "Failed to extract ${FILENAME}"; exit 1; }

echo "Deleting ${FILENAME}"
rm "${FILENAME}"

echo "Moving executable"
mv commitlint.* tools/
chmod +x tools/commitlint.*

The above script is mostly POSIX compliant (curl for example is not a POSIX standard).

I move the binary into my tools directory, this has to be replaced with something more "global".

[RovingStone]

@Wrench56 It seems to me that your assumption does not contradict mine and does not cancel it. Let me make a few comments.

pip wouldn't make sense either

pip makes sense for Python projects.

downloadable installation script (curl is generally on most machines even on Windows) that installs the binary from GitHub

I'm working in a restricted environment, where an access to Internet from CI is limited, scripts can't download from GitHub. We have mirrors on the corporate network for many languages, such as PyPI, NPM and crates.io instead. It's possible to store binaries in artifacts storage like JFrog's Artifactory or Nexus. What I really want is to reduce complexity, i.e. remove additional scripts and helpers.

If you want to download binaries from GitHub I could recommend https://github.com/zyedidia/eget tool

[Wrench56]

Ah, I see your point. There is an NPM based version of commitlint out there. I perceive any non-general package manager for general tooling as evil... regardless, I hope you will get the support needed for PyPi.