As a new Twine maintainer I've been running into questions like:
* Now that Warehouse doesn't use "register" anymore, can we deprecate it from distutils, setuptools, and twine? Are any other package indexes or upload tools using it? https://github.com/pypa/twine/issues/311
* It would be nice if Twine could depend on a package index providing an HTTP 201 response in response to a successful upload, and fail on 200 (a response some non-package-index servers will give to an arbitrary POST request).
I do not see specifications to guide me here, e.g., in the official guidance on hosting one's own package index https://packaging.python.org/guides/hosting-your-own-index/ . PEP 301 was long enough ago that it's due an update, and PEP 503 only concerns browsing and download, not upload.
I suggest that I write a PEP specifying an API for uploading to a Python package index. This PEP would partially supersede PEP 301 and would document the Warehouse reference implementation. I would write it in collaboration with the Warehouse maintainers who will develop the reference implementation per pypa/warehouse/issues/284 and maybe add a header referring to compliance with this new standard. And I would consult with the maintainers of packaging and distribution tools such as zest.releaser, flit, poetry, devpi, pypiserver, etc.
Per Nick Coghlan's formulation, my specific goal here would be close to:
> Documenting what the current upload API between twine & warehouse actually is, similar to the way PEP 503 focused on describing the status quo, without making any changes to it. That way, other servers (like devpi) and other upload clients have the info they need to help ensure interoperability.
Since Warehouse is trying to redo its various APIs in the next several months, I think it might be more useful to document and work with the new upload API, but I'm open to feedback on this.
After a little conversation here on distutils-sig, I believe my steps would be:
1. start a very early PEP draft with lots of To Be Determined blanks, submit as a PR to the python/peps repo, and share it with distutils-sig
2. ping maintainers of related tools
3. discuss with others at the packaging sprints https://wiki.python.org/psf/PackagingSprints next week
4. revise and get consensus, preferably mostly on this list
5. finalize PEP and get PEP accepted by BDFL-Delegate
6. coordinate with PyPA, maintainers of `distutils`, maintainers of packaging and distribution tools, and documentation maintainers to implement PEP compliance
Thoughts are welcome. I originally posted this at https://github.com/pypa/packaging-problems/issues/128 .
I'm making a python package for something python Gedit/Pluma/Xed plugin.
Like other lots of other packages that use Gtk, I use glib-compile-schemas  at install time.
I do this by using a custom setup.py- similar to this file this from flux:
https://github.com/xflux-gui/fluxgui/blob/master/setup.py#L81(other app, like Meld to something similar)
It looks like there are a lot of changes happening to setuptools, will this continue to work or will it break one day ?
This isn't the only file I'd like to generate at install time, but might be the hardest to work around if I can't.
The other custom action I'm going looking at is setting `--install-lib` to the editors plugin directory (this varies depending on: Operating system and is the user root ?)
I'm using use pip for this, as the install story for most python plugins for these editors is nonexistant - people have to copy the files to some place manually, and instructions usually miss out Windows and OSX.
 glib-compile-schemas takes an XML file and generates a binary GVariant file.
To quote the blog post
> To further increase the security of Python package downloads, we're adding a new beta feature to the Python Package Index: WebAuthn support for U2F compatible hardware security keys as a two-factor authentication (2FA) login security method. This is thanks to a grant from the Open Technology Fund, coordinated by the Packaging Working Group of the Python Software Foundation.
We need your help testing this while it's in beta:
https://wiki.python.org/psf/WarehousePackageMaintainerTesting Later this
week I'll publicize it to some more communities, and then in maybe 10
days, assuming we can quickly fix all the urgent bugs we find, we'll
remove the "beta" badge.
During this testing period, if things go awry, there's a chance we will
need to wipe tokens from users' accounts, so if you choose to try it,
please be forewarned. That's why you have to have a PyPI-verified email
address on your user account before trying the feature, to make
potential account recovery smoother.
Thanks to the Open Technology Fund for funding this work. More progress
reports at the Packaging Working Group's wiki page:
I've developed a small C library and a much larger Python native
extension that uses that library. The native extension has no
dependencies other than that small C library.
While the library is useful on its own, I'm thinking it would be good to
include the library's source directly with my native extension's source
when I upload to PyPI, so that it can be easily built for arbitrary
platforms without me having to create wheels for them.
Is this a known approach? Have people done this before?
For reference, the C library, which currently builds with autotools, is
And the Python library and native extension, which currently builds with
setuptools and uses cffi, is here:
Thanks for any guidance!
A few folks will be getting together on Saturday and doing a short
in-person sprint on some Python packaging & distribution tools, around
10am-4pm ET, at a coworking space/lounge in New York City.
A few packaging/distribution folks, e.g., a Twine contributor, a pip bug
fixer/triager, and a Warehouse maintainer (me), are confirmed as coming.
I figure we'll review some open pull requests, triage bugs to find ones
we can close as no longer reproducible, and explain stuff to each other.
I think we've already run out of space for who can participate in
person, but please feel free to hang out and chat with us via IRC! I'll
be on Freenode IRC (#pypa-dev) as user "sumanah". And that way logs of
our conversations will also be available at
(If you have never contributed to Python packaging/distribution tools
before, and you want to start, this is probably not the best event for
you; let me know, and I'll set up a more introductory event in the future.)
Warehouse project manager
Seems like most of the pip bugmail I get now is lockbot messages
telling me that a bug that hasn't received any discussion for a long
time now can't have any more discussion. Is that really needed? The
github UI shows the lock status of bugs itself...