Repository navigation
Conversation
dcio not being on PyPI has become a running cost. It appears in EKDIST's install_requires, where pip cannot resolve it; in two CI workflows that install it from git before anything else; and in HJCFIT's ImportError text. Publishing removes all three. Adds an MIT LICENSE. dcio had none at all, which meant "all rights reserved" by default -- nobody could legally use what was about to be uploaded. MIT rather than a copyleft licence because dcio sits underneath SCALCS (GPL-2.0-only) and HJCFIT (GPL-3.0), and those two are mutually incompatible: any GPL choice for the foundation would conflict with one of its own consumers. EKDIST is already MIT. Completes the packaging metadata: readme, licence, classifiers, keywords and project URLs. Without a readme the PyPI page would have been a bare title. The workflow holds no API token; PyPI verifies the workflow's OIDC identity instead. A version number cannot be reused once uploaded, so publishing runs only on a v* tag. Every push still builds and checks, so a tag is only ever cut from something already known to build. Three build gates: twine check --strict, an assertion that exactly one py3-none-any wheel is produced (dcio is pure Python and should stay that way), and a build of the wheel from the unpacked sdist alone, which is the only way to catch a file missing from the source distribution. Verified locally: both artifacts build, twine check passes, the wheel carries all four subpackages and the licence, and the Qt viewer is correctly excluded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
dcio not being on PyPI has become a running cost: it appears in EKDIST's
install_requireswhere pip cannot resolve it, in two CI workflows thatinstall it from git before anything else, and in HJCFIT's
ImportErrortext.Publishing removes all three.
The name
dciois available on PyPI.dcio had no licence at all
No
LICENSEfile, no declaration inpyproject.toml, nothing in the README.That means all rights reserved by default — nobody could legally use what
was about to be uploaded.
Added MIT. The reasoning matters more than the choice: dcio sits underneath
SCALCS (GPL-2.0-only) and HJCFIT (GPL-3.0), and those two are mutually
incompatible. Any copyleft licence on the foundation would conflict with one
of its own consumers, and GPL would additionally force EKDIST (MIT today) to
change. A permissive licence at the bottom of the stack constrains nobody.
Packaging metadata
readme,license,license-files, classifiers, keywords and project URLs.Without a readme the PyPI page would have rendered as a bare title.
Publishing
No API token in the repository. PyPI verifies the workflow's OIDC identity
instead (Trusted Publishing), so there is no secret to leak, rotate, or hand
to anyone.
A version cannot be reused once uploaded, so
publishruns only on av*tag. Every push still builds and checks, so a tag is only ever cut from
something already known to build.
Three build gates:
twine check --strict— catches metadata that renders badly or fails upload;py3-none-anywheel — dcio is pure Python and should staythat way; if it ever stops being true, the wheel filename changes and this
notices;
file missing from the source distribution.
Verified locally
Both artifacts build,
twine check --strictpasses on both, the wheel carriesall four subpackages plus the licence, and the Qt viewer is correctly excluded.
What you need to do
I have not touched any credential and will not. Before the tag can publish,
register a pending publisher at https://pypi.org/manage/account/publishing/:
dcioDCPROGSdciorelease.ymlpypiOnce that exists and this PR is merged, tell me and I will tag
v0.1.0.🤖 Generated with Claude Code