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 .
--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
Hi,
We are testing team working on Smart Metering Implementation Programme and use pySerial 2.7. Our IT team is preparing an OS build with all the required tools in it. To silently install the tool they them in MSI. I was wondering if you have this in MSI format and can share it with us?
Looking forward to your reply.
Regards
Saqib Rashid
This electronic message contains information from Telef?nica UK Limited which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email. Switchboard: +44 (0)113 272 2000 Contact: www.o2.co.uk/contactus Telef?nica UK Limited, 260 Bath Road, Slough, Berkshire SL1 4DX. Registered in England and Wales: 1743099. VAT number: GB 778 6037 85
Channelling the experts for advice on travis. After being absent for a couple of weeks my travis builds have started failing
The problem is seems to be related to this message in the failing builds
> 3.5 is not installed; attempting download
this is later followed by
> Downloading archive: https://storage.googleapis.com/travis-ci-language-archives/python/binarie...
> 0.48s$ curl -sSf -o python-3.5.tar.bz2 ${archive_url}
> 13.65s$ sudo tar xjf python-3.5.tar.bz2 --directory /
my base python in .travis.yml is
> python: 3.5
and in the matrix I have this
> matrix:
> exclude:
> # Exclude the default Python 3.5 build
> - python: 3.5
> include:
> - os: linux
> env:
> - UNICODE_WIDTH=16
> - MB_PYTHON_VERSION=2.7
> - os: linux
> env: ........
...............
I see no pattern in which are failing and which succeed
--
Robin Becker
Greetings!
my organization uses Python across it's departments but the recent versions
of Python do NOT have an MSI download. We use SCCM for deployment of
software and because the downloads are all .exe based, the program is no
longer in compliance with my organization's security policies. I've looked
and I've looked but I cannot find an MSI for this program.
IT Guy.
Python Software Foundation has published a Request for Information
seeking software developers to add these features to Warehouse (PyPI):
* Verifiable cryptographic signing of artifacts (PEP 458/TUF or simiilar)
* Technical infrastructure and methods for automated detection of
malicious package uploads
More info:
https://github.com/python/request-for/blob/master/2019-Q4-PyPI/RFI.md
We'd like for potential contractors & other experts to keep discussion
at the Discourse forum
https://discuss.python.org/c/python-software-foundation/pypi-q4-rfi ,
especially on these questions:
• What methods should we implement to detect malicious content?
https://discuss.python.org/t/what-methods-should-we-implement-to-detect-m...
and
* PEPs 458 and 480 offer different levels of security; which (if either)
should we implement? Which one has more appropriate operational
efficacy? Should we use TUF (The Update Framework) or another approach?
https://discuss.python.org/t/which-cryptographic-signing-approach/2241
and more generally:
* What should community acceptance criteria be?
* How feasible is it to implement this on PyPI?
* What features do PyPI administrators need to make use of these
features in the future?
* What work would the developer need to do to make these features more
maintainable by future Warehouse maintainers?
--
Sumana Harihareswara
PyPI project manager
Changeset Consulting
https://changeset.nyc
