Feature Request: Native Private Python Package Registry

[castillouparela]

Code of Conduct

• I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

✨ Feature Request: Native Support for Private Python Packages in GitHub Packages

Current Problem

GitHub Packages provides excellent private registry support for many languages, but Python lacks native support despite being one of the most popular languages worldwide.

Supported Private Registries

Language	Private Registry URL	Status
npm	npm.pkg.github.com	✅ Supported
RubyGems	rubygems.pkg.github.com	✅ Supported
Maven	maven.pkg.github.com	✅ Supported
Gradle	maven.pkg.github.com	✅ Supported
NuGet	nuget.pkg.github.com	✅ Supported
Docker	ghcr.io	✅ Supported
Python (PyPI)	pypi.pkg.github.com	❌ Missing

Current Python workarounds are brittle:

• pip install git+https://github.com/org/repo.git@v1.0.0 (requires SSH keys for private repos)
• Manual GitHub Releases + custom install scripts
• GitHub Actions artifacts (no dependency resolution)

Requested Specification

Private Python Package Registry: https://pypi.pkg.github.com/{owner}/{repo}/simple/

Required Features:

├── PEP 503 Simple Repository API compatibility
├── Support for wheel (.whl) & sdist (.tar.gz) formats
├── PEP 658 JSON metadata endpoints
├── GITHUB_TOKEN authentication (no additional secrets needed)
├── Dependency resolution across repos in same org
└── GitHub Actions integration for automated publishing

Desired Developer Experience

1. Publishing (GitHub Actions)

# .github/workflows/publish.yml
name: Publish Python Package
on: [push, release]
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-python@v5
      with: { python-version: '3.12' }
    - run: python -m pip install build twine
    - run: python -m build
    - run: |
        twine upload dist/* 
        --repository-url https://pypi.pkg.github.com/${{ github.repository }}
        --username github-actions 
        --password ${{ secrets.GITHUB_TOKEN }}

2. Consuming Packages

# ~/.pypirc (one-time setup)
[pypi.pkg.github.com]
repository: https://pypi.pkg.github.com/myorg/myrepo

# Install private package
pip install my-private-package --index-url https://pypi.pkg.github.com/myorg/myrepo

# Or in pyproject.toml
[[tool.poetry.source]]
name = "github-myorg"
url = "https://pypi.pkg.github.com/myorg/myrepo"

3. pyproject.toml Example

[build-system]
requires = ["setuptools>=65.0", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "my-private-package"
version = "1.0.0"
dependencies = [
    "requests>=2.28.0",
    "internal-org-another-package>=0.2.0",  # Cross-repo dependency
]

Current Pain Points

❌ No native dependency resolution for private packages
❌ SSH key management for git+ installs
❌ No visibility into private dependency versions
❌ Broken CI/CD when SSH keys rotate
❌ Manual artifact distribution

What part(s) of the article would you like to see updated?

Business Impact

• 400K+ Python repos on GitHub would benefit
• Enterprise teams blocked by missing private package support
• Data Science/ML workflows crippled without internal package sharing
• Competitors (GitLab, Azure Artifacts) already support private PyPI

Priority: 🚀 High

Python ranks #1 in TIOBE Index and powers 80%+ of ML/Data Science. Native support would unlock massive adoption.

Existing discussion: GitHub Roadmap #94 (4+ years old, 200+ 👍)

Additional information

Additional Information

Use Case: This feature is critical for private repositories and enterprise internal packages.

Reproducibility: 100% - Python developers cannot use GitHub Packages for private Python packages today.

Affected Users:

• Enterprise teams publishing internal libraries (security tools, ML models, infra utilities)
• Private repositories where packages must remain internal
• Teams with 10-1000+ developers sharing private dependencies

Context: Companies need to share proprietary Python packages internally without exposing source code or using external registries. Current git+ workarounds fail in CI/CD and require complex SSH key management across hundreds of runners.