#twine
1 messages · Page 1 of 1 (latest)
nit: can you put the channel alphabetically in the list on the left? move it before virtualenv
It's really just that twine's always the afterthought. Genuinely the project doesn't seem to really need to exist anymore
Not all tools have an upload feature so twine is kind of still needed for those who don’t have an alternative
yeah, I use either pypi-publish or twine directly, never had any issues with it 🙂 and looks really good now there's coloured logs during upload
I guess if anyone made twine a pip plugin, that might help solve one of the main "too many tools" conversations
If only pip had a plugin system
I doubt it’d help, when people say there are too many tools they don’t generally mean there are too many commands but there are too many things to install. Even as a plugin you still need to install it separately from pip itself.
For sure a concern. I guess if pip had a plugin system, and pip-upload was a plugin that basically implemented twine, then it would have less of a distance to traverse to be incorporated directly into pip
hmm, there’s three tools with clear responsibilities:
build: build packages from a source treetwine: upload built packages to PyPIinstaller: install packages into an environment (venv or system)
pip exists to install packages (including from source trees) into venvs. it therefore has to be able to build, download, dep resolve, and modify venvs.
it can therefore do what build and installer can do, but not very cleanly: It’s hard to tell it not to do a lot of the other things it does.
e.g. to make it work like python -m installer --destdir="$pkgdir" dist/*.whl, you need to do something like
PIP_CONFIG_FILE=/dev/null pip install --isolated --root="$pkgdir" --ignore-installed --no-deps dist/*.whl
and I’m not sure I got that right.
So I don’t think pip is the base tool we should extend to cover more use cases. I don’t use any of the named tools manually at all (except for debugging).
- I let
hatchmanage my dev projects (multiple environments per projects to run commands in, likehatch run test:covorhatch run docs:build) - I let
gh-action-pypi-publishcall twine for me - I use
buildandinstallerin scripts to wrap python packages into OS managed packages
All usage of twine broken. Including the publish action. https://github.com/pypa/twine/issues/1125 Yanking 5.1.0 would fix now now while PR in review.
TIL that pip install twine is not pure Python.
Someone tried to install twine on their Android phone and got an error about not having a Rust compiler: https://paste.pythondiscord.com/G5WQ.
Looks like nh3, a dependency of readme-renderer, has a Rust extension.
I don't have a strong enough opinion to push for change, I was just surprised.
I feel like it's bad DX to not have native support for official tooling.
Previously reported at https://github.com/pypa/twine/issues/1015, closed as readme-renderer is the only tool for the job, and it's up to them to provide wheels (or presumably not use nh3)
That links to https://github.com/pypa/readme_renderer/commit/9c2eb81301bc230f2795cf7e6dc2c23f5815ea41 where nh3 was added as a replacement for bleach, which is no longer supported
Or rather bleach is deprecated and only minimally supported https://github.com/mozilla/bleach/issues/698
nh3 seems to provide many wheels for many different architectures (PowerPC, ARMv7, …) and all Python versions from 3.7 up, so it’s really not clear to me why your environment isn’t able to pick up the right wheel.
Are you maybe on a very obscure architecture or is there a bug that prevents your environment from picking up the right wheel?
is there even a wheel tag for android? maybe that is the case?
the report was for Android
also, I guess pre-building iOS/Android wheels in CI might be slightly tricky
Beeware will be working on adding iOS/Andoid support to pip/cibuildwheel/etc this year https://beeware.org/news/buzz/2024q4-roadmap/
I guess something needs adding to PyPI as well?
it's actually surprising that twine requires readme_renderer. I would expect that to be an optional check (since IIRC pypi checks files with readme_renderer on upload)
I would have thought the main thing twine has over uv is being implemented in Python, and not requiring rust. If it requires rust anyway, not sure what it has over uv publish. 😉
If Python for Android isn’t yet officially supported, but support is coming, I think the answer to the request is:
You have to wait a little, and thanks to the great people working on #cibuildwheel, you’ll get that in a few months
would maturin temporarily installing rustc/cargo help?
i.e., is the problem rustc missing or is the problem rust not being supported at all?
some dummy package that would setup some basic rust would be nice anyway
I recently got burnt by forgetting to remove a 'Private :: Do Not Upload' from a package I did indeed want to upload.
Is there a twine flag for this already?
Also I had a dependency with a direct URL, that twine didn't tell me about
Related: #pypi message
Also related https://github.com/astral-sh/uv/issues/8214
Oh actually sorry I read that backwards
I thought you uploaded something you didn't want to! Not the other way around 🙂
the most confident solution to avoiding accidental publishing is never generating an all-project scoped pypi token: without credentials, you can't publish to pypi
True, but with an invalid classifier, nobody else in your organisation can make the mistake of publishing it either.
Do I actually need .pypirc to use twine nowadays? Can it e.g. grab credentials from a system keyring instead? (I don't think I actually fully understand my system keyring, but.)
Yeah, we use the keyring extra to integrate with whatever backend you want: https://twine.readthedocs.io/en/stable/#keyring-support