PEP 759, External Wheel Hosting; initial published version
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Ethan Smith <etsmith@nvidia.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
---------
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Ethan Smith <etsmith@nvidia.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
See #2, #1385 for context. Superseeds #1565.
This is the minimal core Sphinx support part, adding a bare minimum of useful things to get Sphinx to build and deploy, whilst not affecting the current build system. There is no theming or custom parsing needed to properly deal with PEPs.
- `build.py` - build script
- `conf.py` - Sphinx configuration
- `Makefile` - new targets for Sphinx
- `.gitignore` - add ignores for `venv` and `package` directories
- `contents.rst` - Sphinx page to discover all PEPs
- `deploy-gh-pages.yaml` - builds and deploys to github pages
- `requirements.txt`
* Check created date exists & matches format, and fix non-conforming
* Automatically fix mixed EoLs on checkin and in one PEP
* Add rst-directive-colons check, fix issue it found and refine regex
* create package target
the peps are built... may as well publish a tarball directly from travis.
python.org hosting is being updated and i'm trying to move it away from local
disk storage, which the current pep integration relies on.
this will allow me python.org to pull the tarball out of S3 and do it's work.
* packager: push to s3 after success
Barry Warsaw
Łukasz Langa
Adam Turner
Hugo van Kemenade
CAM Gerlach
Ernest W. Durbin III
Nick Coghlan
Brett Cannon