On 9 May 2018 at 04:09, Sumana Harihareswara <s...@changeset.nyc> wrote:
> 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. > That's effectively what PEP 517 did for the legacy setup.py-centric sdist format, with just a single paragraph referencing the previous de facto standard and giving that version a name: https://www.python.org/dev/peps/pep-0517/#source-trees The equivalent here would be to call the existing upload interface the "v1 upload API", and cite the relevant Warehouse endpoint URL as the reference implementation for it. While I initially wasn't a fan of that idea, the effectiveness of the approach in PEP 517 now makes me agree it could work well here, too. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
-- Distutils-SIG mailing list distutils-sig@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/V3I6KJHRBGKSV6CCUOCWFOCDW7PGX3NG/
