Skip to main content

compilecode

compilecode compiles a project's Python modules to native .so extension modules with Nuitka. The original .py sources and bytecode are removed afterwards. There is no key and no runtime decryption: the compiled modules are imported directly by Python.

Usage

Drop-in one-liner, run from the project root:

python -m compilecode .

Or, after installing the package (pip install -e .):

compilecode path/to/project

Options:

  • --strip-docstrings removes docstrings from the compiled modules.

The exit code is 0 on success and 1 if any module failed to compile or its source was not fully removed.

Drop-in swap (Docker)

The reference references/Dockerfile keeps the same compileit.sh one-liner against $DOCKERHOME, so existing setups swap in without other changes. The line now compiles the project to .so modules with Nuitka instead of encrypting it. No key is generated or shipped in the image, so there is nothing to store or rotate. The builder stage installs nuitka, and the runtime stage no longer installs git, vim or dos2unix.

Ignoring files

Place a .compilecodeignore file in the project root to override which files are compiled. It holds one pattern per line; blank lines and lines starting with # are ignored. A pattern matches files that are left as plain Python. A line starting with ! forces a file to be compiled even if another rule would skip it.

Packaging

compileit.sh ships inside the installed compilecode/ package. It runs python -m compilecode and honours the PYTHON environment variable to pick the interpreter.

Releasing to PyPI / TestPyPI

release.sh versions, builds, and publishes the package. Everything runs inside the docker compose test container — you only need Docker on the host; build, twine, and setuptools_scm are never installed locally.

The version lives in git tags (via setuptools_scm): you never edit a version by hand. release.sh computes the next one, tags the commit, builds the sdist + wheel, uploads, and pushes the commit and tag back.

./release.sh <testpypi|pypi> [version] [options]

Version selection (pick at most one; default is a patch bump):

You pass Version used Example
(nothing) patch bump of the latest tag 0.1.3 → 0.1.4
(nothing), but HEAD is already on a tag that tag is reused (so testpypi → pypi publishes the same version) 0.1.3
--minor minor bump, patch reset 0.1.3 → 0.2.0
--major major bump, minor+patch reset 0.1.3 → 1.0.0
--version X.Y.Z exactly that 2.5.1

Options

  • --dry-run — compute the version, build, and twine check only. Makes no git changes, uploads nothing, pushes nothing. Run this first.
  • --no-push — publish but skip git push --follow-tags.

Authentication (only needed for a real upload). Either works:

  1. A .pypirc with [pypi] / [testpypi] sections (the default when no token env is set). It is searched as $PYPIRC, then ./.pypirc, then ~/.pypirc, mounted read-only into the container, and used via twine upload --repository <target>. The [testpypi] section must include its repository = https://test.pypi.org/legacy/ line:

    [pypi]
      username = __token__
      password = pypi-AgEI...
    [testpypi]
      repository = https://test.pypi.org/legacy/
      username = __token__
      password = pypi-AgEI...
    
  2. export TWINE_API_TOKEN="pypi-...." — a single token that takes precedence over .pypirc (matches twine's own env-over-file rule). Handy for CI.

Create tokens at https://pypi.org/manage/account/token/ (or test.pypi.org).

First release

./release.sh testpypi --version 0.1.0 --dry-run   # rehearse, no side effects
./release.sh testpypi --version 0.1.0             # tag v0.1.0, publish to TestPyPI
./release.sh pypi     --version 0.1.0             # same version → real PyPI

Routine release after merging new commits:

./release.sh testpypi --dry-run    # shows the next patch, e.g. 0.1.1
./release.sh testpypi              # tag v0.1.1, publish to TestPyPI, push
./release.sh pypi                  # HEAD on v0.1.1 → reuse → publish to PyPI

Verify a TestPyPI upload installs (its deps still come from real PyPI):

pip install --index-url https://test.pypi.org/simple/ \
    --extra-index-url https://pypi.org/simple/ compilecode

Try it end-to-end (smoke test)

references/examples/sample-project/ is a small app that exercises the tricky cases (nested relative imports, a dataclass, a data file, an entry script). Its smoke.sh builds the real two-stage Docker image — compile under full python:3.13, run under python:3.13-slim — and asserts the compiled app runs while its .py sources are gone:

./references/examples/sample-project/smoke.sh

Metadata

Release files for compilecode 0.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for compilecode 0.0.0
File Size Uploaded Provenance Actions
compilecode-0.0.0.tar.gz 10.1 kB Without provenance Details for compilecode-0.0.0.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for compilecode 0.0.0
File Interpreter ABI Platform Actions
compilecode-0.0.0-py3-none-any.whl Python 3 none any Details for compilecode-0.0.0-py3-none-any.whl

Total release size: 19.5 kB

Release files / compilecode-0.0.0.tar.gz

Download URL compilecode-0.0.0.tar.gz
Size 10.1 kB
Tags Source
SHA-256 checksum
How to use checksums
137fd2b4fec0ee1eaa04f9cdbc1a0f00a512191f85eefa83c2704fcb6123b254
BLAKE2b-256 checksum
How to use checksums
b75283a543004b63cb797e7d0b969481ce8f8e2beec2c06d46ad376c6b452b68
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.13.18

Release files / compilecode-0.0.0-py3-none-any.whl

Download URL compilecode-0.0.0-py3-none-any.whl
Size 9.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
dca0b80aafd224a4be8a364f5b80e1b3937bbdd4e718c287e724519a84b01bdf
BLAKE2b-256 checksum
How to use checksums
d1367eec4488c649251e448c0e9e8d2393956d5b299eece899ee06d7c66fc61b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.13.18

Security for compilecode 0.0.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

0.0.0 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page