You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While .whl are preferred by pip users, having the canonical .tar.gz makes downstream packaging more predictable (a la bernhard-42/jupyter-cadquery#38).
On some other projects, I have been:
building the sdist and bdist_wheel in CI
immediately running twine check on the files
capturing the distributions cryptographic identity with cd dist && sha256sums * > SHA256SUMS
uploading those as CI artifacts
testing against those (instead of in-tree)
for lab extensions, the first step is something akin to:
run: |
jupyter labextension list
jupyter labextension list 1>labextensions 2>&1
cat labextensions | grep "my-lab-npm-package.*OK.*my_py_module"
Then, when release time comes around, you'd:
download the master builds off CI
verify those hashes one more time
dump them in a tag/release in the web ui
twine upload them
verify the hashes on PyPI
This leaves a nice trail of validation, and reduces weird packaging surprises from being built on the magic build computer.
The text was updated successfully, but these errors were encountered:
While
.whl
are preferred bypip
users, having the canonical.tar.gz
makes downstream packaging more predictable (a la bernhard-42/jupyter-cadquery#38).On some other projects, I have been:
sdist
andbdist_wheel
in CItwine check
on the filescd dist && sha256sums * > SHA256SUMS
Then, when release time comes around, you'd:
master
builds off CItwine upload
themThis leaves a nice trail of validation, and reduces weird packaging surprises from being built on the magic build computer.
The text was updated successfully, but these errors were encountered: