Publishing

Three audiences, three distribution channels:

• Mac app users - install via the in-app PDK panel from a .lumpdk file you publish.
• Python scripters - pip install your_pdk from PyPI or a private index.
• Internal teams - a shared NFS / git checkout, or a private PyPI mirror.

You don’t have to pick one. A typical foundry PDK ships all three from the same source tree.

Keep distribution identity separate from product identity: PyPI’s distribution name can be lumicron-pdk-tinyphot, the Python/.lumpdk package name can be tinyphot, and the human display name can be “TinyPhot Research PDK”. Record the latter two in META["package-name"] and META["name"] respectively.

Versioning

Use Semantic Versioning. What “breaking” means for a PDK:

End-user scripts pin your_pdk == 1.2.* for a stable cross-section; use an upper bound such as >=1.2,<2 if accepting compatible updates. A lower bound alone also permits future breaking releases.

Publishing to PyPI

Your PDK is an ordinary Python package - pyproject.toml, a wheel, pip install. The convention for placement:

[project]
name = "lumicron-pdk-tinyphot"
version = "0.1.0"
requires-python = ">=3.12"
# Pin the API distribution version validated by your release tests.
dependencies = ["lumicron"]

[tool.setuptools.packages.find]
where = ["src"]
include = ["lumicron.pdks.*"]
namespaces = true

Two non-obvious bits:

• Do not replace API package files. The API owns lumicron/__init__.py and lumicron/pdks/__init__.py; do not ship replacements in your PDK wheel. Package discovery with namespaces = true can include your nested PDK directory without those parent files. Test the wheel in a clean environment alongside the matching API distribution.
• Source layout. Put your code at src/lumicron/pdks/<your_pdk>/. The PyPI wheel and the .lumpdk bundle both consume the same directory.

Distribution name conventions:

• lumicron-pdk-<your_pdk> - recommended. Distinct on PyPI, telegraphs what it is.
• <your_pdk>-pdk-lumicron - if your PDK has a strong existing brand (e.g. sky130).

Publishing a .lumpdk

Build from the importable package itself:

python -m lumicron_pdk.packaging lumicron.pdks.tinyphot \
  --output-directory dist/1.2.0

This writes dist/1.2.0/tinyphot.lumpdk; the filename must match package-name. Distribute the archive with its release notes and tested Lumicron/API build identity. Users load it from the app’s Load PDK command. A marketplace is not part of this alpha.

What to put in your README

The conventional shape works:

1. One-line description. What process, what’s special.
2. Install - pip install … and .lumpdk link.
3. Quick start - 5-10 line script that imports the PDK and routes between two of its components. Make sure it actually runs.
4. Layer table - the output of LAYER.print_rules(), copy-pasted.
5. Component list - names + 1-line descriptions.
6. Foundry / process notes - substrate, BOX thickness, key min rules.
7. License + foundry agreement notes - if your PDK includes confidential geometry, say so.

End users find a foundry PDK by Googling - make the README’s first line match what they’ll search for.

CI / release pipeline

Recommended steps for a tagged release:

1. Run the test suite. Every component instantiates without raising, every profile renders a non-empty FlexRoute, every cross-layer route uses the registered transition.
2. Run end-to-end script tests. A handful of scripts that import your PDK, build a small chip, and verify the resulting GDS has the expected layers and reasonable polygon counts. Catches regressions in routing / transitions that unit tests miss.
3. Build the wheel - python -m build.
4. Build the .lumpdk - python -m lumicron_pdk.packaging <package> --output-directory dist.
5. Publish to PyPI - twine upload dist/*.whl.
6. Attach the .lumpdk to the GitHub release.

Measure build and validation time for your PDK. Wire it up early - it’s much harder to retrofit.

Marketing your PDK

If you’re publishing to a wider audience:

Show, don’t list. A short video or screen recording of a script that imports your PDK and routes between two non-trivial components is worth more than a feature list.

Be specific about what’s not covered. A PDK that says “production-ready for [process]” but secretly omits half the device library will burn its first user. Be honest about scope.

Pin and test a lumicron version. Put the dependency range in pyproject.toml for wheels and state the tested Lumicron app/API versions in release notes. The current .lumpdk installer does not enforce a lumicron_required manifest field, so CI and explicit release notes are the compatibility gate today.