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 .
PyPI and Test PyPI now support the creation of API Tokens for use when uploading projects to PyPI, thanks to work funded by the Open Technology Fund.
These tokens are created by default with the same upload permissions as the User creating them, but can also be scoped to specific projects that User has upload privileges for.
This is the first step in enforcing that Users with Two-Factor Authentication enabled must use an API Token when uploading to PyPI, rather than their password.
After the Beta we’ll announce the general availability of these features and timeline for enforcement of API Tokens for Two-Factor Authentication enabled accounts.
Read more on how you can help to test this feature at: https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress...
-Ernest W. Durbin III
Director of Infrastructure
Python Software Foundation
On behalf of the PyPA, I am pleased to announce that pip 19.2 has just
The highlights of this release are:
- Python 3.4 support has been dropped
- Support for "yanked" files on package indexes (PEP 592)
- keyring can now be used for managing credentials
- A new `pip debug` command, for helping debug installations
- Many bug fixes and lots of minor improvements
We've also documented how Python 2 support in pip, would be maintained
going forward. 
To install pip 19.2, you can use get-pip (as described in ) or run:
python -m pip install --upgrade pip
Note that if you are using a version of pip supplied by your distribution
vendor, vendor-supplied upgrades will be available in due course.
The pip development team is extremely grateful to everyone in the community
for their contributions. Thanks to everyone who put so much effort into the
new release. Many of the contributions came from community members, whether
in the form of code, participation in design discussions and/or bug reports.
I'm stepping away from several things in the Python community. I've served
as the maintainer of packaging.python.org and Twine for a while, but it's
time for me to move on.
I'm looking for someone to take on primary responsibility for
packaging.python.org and another person to help share the load for Twine.
If you or someone you know is interested, please reply to this thread and
let me know.