PyPI and Uploading Documentation
Hey! First, for anyone who isn't aware we recently migrated PyPI and TestPyPI so that instead of storing files and documentation locally (really in a glusterfs cluster) it will store them inside of S3. This will reduce maintenance overhead of running PyPI by two servers since we'll no longer need to run our own glusterfs cluster as well as improve the reliaiblity and scalability of the PyPI service as a whole since we've had nothing but problems from glusterfs in this regard. One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. It's not a well supported feature and I feel that it's going outside of the core competancy for PyPI itself and instead PyPI should be focused on the files themselves. In addition since the time this was added to PyPI a number of free services or cheap services have came about that allow people to sanely upload raw document without a reliance on any particular documentation system and we've also had the rise of ReadTheDocs for when someone is using Sphinx as their documentation system. I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas. The rough idea I have currently is to simply disable new documentation uploads and add two new small features. One will allow users to delete their existing documentation from PyPI and the other would allow them to register a redirect which would take them from the current location to wherever they move their documentation too. In order to prevent breaking documentation for projects which are defunct or not actively maintained we would maintain the archived documentation (sans what anyone has deleted) indefinetely. Ideally I hope people start to use ReadTheDocs instead of PyPI itself. I think that ReadTheDocs is a great service with heavy ties to the Python community. They will do a better job at hosting documentation than PyPI ever could since that is their core goal. In addition there is a dialog between ReadTheDocs and PyPI where there is an opportunity to add integration between the two sites as well as features to ReadTheDocs that it currently lacks that people feel are a requirement before we move PyPI's documentation to read-only. Thoughts? * Out of ~60k projects only ~2.8k have ever uploaded documentation. It's not easy to tell if all of them are still using it as their primary source of documentation though or if it's old documentation that they just can't delete. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Fri, May 15, 2015 at 9:48 AM, Donald Stufft <donald@stufft.io> wrote:
Hey!
First, for anyone who isn't aware we recently migrated PyPI and TestPyPI so that instead of storing files and documentation locally (really in a glusterfs cluster) it will store them inside of S3. This will reduce maintenance overhead of running PyPI by two servers since we'll no longer need to run our own glusterfs cluster as well as improve the reliaiblity and scalability of the PyPI service as a whole since we've had nothing but problems from glusterfs in this regard.
One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. It's not a well supported feature and I feel that it's going outside of the core competancy for PyPI itself and instead PyPI should be focused on the files themselves. In addition since the time this was added to PyPI a number of free services or cheap services have came about that allow people to sanely upload raw document without a reliance on any particular documentation system and we've also had the rise of ReadTheDocs for when someone is using Sphinx as their documentation system.
I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas. The rough idea I have currently is to simply disable new documentation uploads and add two new small features. One will allow users to delete their existing documentation from PyPI and the other would allow them to register a redirect which would take them from the current location to wherever they move their documentation too. In order to prevent breaking documentation for projects which are defunct or not actively maintained we would maintain the archived documentation (sans what anyone has deleted) indefinetely.
Ideally I hope people start to use ReadTheDocs instead of PyPI itself. I think that ReadTheDocs is a great service with heavy ties to the Python community. They will do a better job at hosting documentation than PyPI ever could since that is their core goal. In addition there is a dialog between ReadTheDocs and PyPI where there is an opportunity to add integration between the two sites as well as features to ReadTheDocs that it currently lacks that people feel are a requirement before we move PyPI's documentation to read-only.
Thoughts?
+1
* Out of ~60k projects only ~2.8k have ever uploaded documentation. It's not easy to tell if all of them are still using it as their primary source of documentation though or if it's old documentation that they just can't delete.
I know I have documentation for at least one project hosted this way. I don't remember how I set that up. :) I assume there will be some way to notify owners of effected documentation. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
On Fri, May 15, 2015 at 8:48 AM, Donald Stufft <donald@stufft.io> wrote:
Hey!
First, for anyone who isn't aware we recently migrated PyPI and TestPyPI so that instead of storing files and documentation locally (really in a glusterfs cluster) it will store them inside of S3. This will reduce maintenance overhead of running PyPI by two servers since we'll no longer need to run our own glusterfs cluster as well as improve the reliaiblity and scalability of the PyPI service as a whole since we've had nothing but problems from glusterfs in this regard.
One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. It's not a well supported feature and I feel that it's going outside of the core competancy for PyPI itself and instead PyPI should be focused on the files themselves. In addition since the time this was added to PyPI a number of free services or cheap services have came about that allow people to sanely upload raw document without a reliance on any particular documentation system and we've also had the rise of ReadTheDocs for when someone is using Sphinx as their documentation system.
I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas. The rough idea I have currently is to simply disable new documentation uploads and add two new small features. One will allow users to delete their existing documentation from PyPI and the other would allow them to register a redirect which would take them from the current location to wherever they move their documentation too. In order to prevent breaking documentation for projects which are defunct or not actively maintained we would maintain the archived documentation (sans what anyone has deleted) indefinetely.
Ideally I hope people start to use ReadTheDocs instead of PyPI itself. I think that ReadTheDocs is a great service with heavy ties to the Python community. They will do a better job at hosting documentation than PyPI ever could since that is their core goal. In addition there is a dialog between ReadTheDocs and PyPI where there is an opportunity to add integration between the two sites as well as features to ReadTheDocs that it currently lacks that people feel are a requirement before we move PyPI's documentation to read-only.
Thoughts?
* Out of ~60k projects only ~2.8k have ever uploaded documentation. It's not easy to tell if all of them are still using it as their primary source of documentation though or if it's old documentation that they just can't delete.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I'm +1 on reducing the responsibilities of PyPI so it can act as an index/repository in a much more efficient manner. I'm also +1 on recommending people use ReadTheDocs. It supports more than just Sphinx so it's a rather flexible option. It's also open source, which means that anyone can contribute to it. I'm curious to hear more about integrations between PyPI and ReadTheDocs but I fully understand if they're not concrete enough to be worthy of discussion. -- Ian
I'm using pypi's documentation hosting for pysdl2-cffi because I thought it would be too difficult to run the documentation generator (which parses documentation comments out of the wrapped C code) on the readthedocs server. Perhaps there is a different way to do it that I'm not familiar with. On Fri, May 15, 2015 at 9:55 AM, Ian Cordasco <graffatcolmingov@gmail.com> wrote:
On Fri, May 15, 2015 at 8:48 AM, Donald Stufft <donald@stufft.io> wrote:
Hey!
First, for anyone who isn't aware we recently migrated PyPI and TestPyPI so that instead of storing files and documentation locally (really in a glusterfs cluster) it will store them inside of S3. This will reduce maintenance overhead of running PyPI by two servers since we'll no longer need to run our own glusterfs cluster as well as improve the reliaiblity and scalability of the PyPI service as a whole since we've had nothing but problems from glusterfs in this regard.
One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. It's not a well supported feature and I feel that it's going outside of the core competancy for PyPI itself and instead PyPI should be focused on the files themselves. In addition since the time this was added to PyPI a number of free services or cheap services have came about that allow people to sanely upload raw document without a reliance on any particular documentation system and we've also had the rise of ReadTheDocs for when someone is using Sphinx as their documentation system.
I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas. The rough idea I have currently is to simply disable new documentation uploads and add two new small features. One will allow users to delete their existing documentation from PyPI and the other would allow them to register a redirect which would take them from the current location to wherever they move their documentation too. In order to prevent breaking documentation for projects which are defunct or not actively maintained we would maintain the archived documentation (sans what anyone has deleted) indefinetely.
Ideally I hope people start to use ReadTheDocs instead of PyPI itself. I think that ReadTheDocs is a great service with heavy ties to the Python community. They will do a better job at hosting documentation than PyPI ever could since that is their core goal. In addition there is a dialog between ReadTheDocs and PyPI where there is an opportunity to add integration between the two sites as well as features to ReadTheDocs that it currently lacks that people feel are a requirement before we move PyPI's documentation to read-only.
Thoughts?
* Out of ~60k projects only ~2.8k have ever uploaded documentation. It's not easy to tell if all of them are still using it as their primary source of documentation though or if it's old documentation that they just can't delete.
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I'm +1 on reducing the responsibilities of PyPI so it can act as an index/repository in a much more efficient manner. I'm also +1 on recommending people use ReadTheDocs. It supports more than just Sphinx so it's a rather flexible option. It's also open source, which means that anyone can contribute to it.
I'm curious to hear more about integrations between PyPI and ReadTheDocs but I fully understand if they're not concrete enough to be worthy of discussion.
-- Ian _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On May 15, 2015, at 09:48 AM, Donald Stufft wrote:
One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes.
I use it for all my packages, mostly because it's easy for my upload workflow: `python setup.py upload_docs`. That said, with the rise of RTD, I have wondered about the usefulness of pythonhosted documentation. And because twine supports secure uploads of code, but not documentation, that unease has grown. So even while I use it, I agree it's time to consider retiring the service. One thing I definitely want to retain though is the link to "Package Documentation" from the project's PyPI page. Please do give us a way to specify that link. The PSF is a supporter of RTD, but let's all make sure they stay in business! https://readthedocs.org/sustainability/#about Cheers, -Barry
On Fri, May 15, 2015 at 9:48 AM, Donald Stufft <donald@stufft.io> wrote:
Hey!
First, for anyone who isn't aware we recently migrated PyPI and TestPyPI so that instead of storing files and documentation locally (really in a glusterfs cluster) it will store them inside of S3. This will reduce maintenance overhead of running PyPI by two servers since we'll no longer need to run our own glusterfs cluster as well as improve the reliaiblity and scalability of the PyPI service as a whole since we've had nothing but problems from glusterfs in this regard.
One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. It's not a well supported feature and I feel that it's going outside of the core competancy for PyPI itself and instead PyPI should be focused on the files themselves. In addition since the time this was added to PyPI a number of free services or cheap services have came about that allow people to sanely upload raw document without a reliance on any particular documentation system and we've also had the rise of ReadTheDocs for when someone is using Sphinx as their documentation system.
I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas. The rough idea I have currently is to simply disable new documentation uploads and add two new small features. One will allow users to delete their existing documentation from PyPI and the other would allow them to register a redirect which would take them from the current location to wherever they move their documentation too. In order to prevent breaking documentation for projects which are defunct or not actively maintained we would maintain the archived documentation (sans what anyone has deleted) indefinetely.
Ideally I hope people start to use ReadTheDocs instead of PyPI itself. I think that ReadTheDocs is a great service with heavy ties to the Python community. They will do a better job at hosting documentation than PyPI ever could since that is their core goal. In addition there is a dialog between ReadTheDocs and PyPI where there is an opportunity to add integration between the two sites as well as features to ReadTheDocs that it currently lacks that people feel are a requirement before we move PyPI's documentation to read-only.
Thoughts?
* Out of ~60k projects only ~2.8k have ever uploaded documentation. It's not easy to tell if all of them are still using it as their primary source of documentation though or if it's old documentation that they just can't delete.
+1 for all the stated reasons. I have a few docs hosted on pythonhosted.org, but it's become a nuisance to maintain since it does not support multiple doc versions like ReadTheDocs, so now I've wound up with documentation for the same projects on both sites. The nuisance comes not so much in the process (like Barry wrote, I've enjoyed the simplicity of `setup.py upload_docs`), but because more often than not I've had to redirect users to the Readthedocs docs to make sure they're using the correct version of the docs. So I wish I were not locked into updating the pythonhosted.org docs and would be happy to retire them altogether (much as I appreciated the service). One question is how this would be handled at the tooling end. setup.py upload_docs would have to be retired somehow. Though it might also be nice if some simple tools were added to make it just as easy to add docs to ReadTheDocs. I know something like upload_docs doesn't really make sense, since RTD handles the checkout and build of the docs. But there's still a manual step of enabling new versions of the docs that it would be nice to make as effortless as `setup.py upload_docs`. I gues that's off-topic for the PyPI end of things though. Erik
On May 15, 2015, at 2:23 PM, Erik Bray <erik.m.bray@gmail.com> wrote:
On Fri, May 15, 2015 at 9:48 AM, Donald Stufft <donald@stufft.io> wrote:
Hey!
First, for anyone who isn't aware we recently migrated PyPI and TestPyPI so that instead of storing files and documentation locally (really in a glusterfs cluster) it will store them inside of S3. This will reduce maintenance overhead of running PyPI by two servers since we'll no longer need to run our own glusterfs cluster as well as improve the reliaiblity and scalability of the PyPI service as a whole since we've had nothing but problems from glusterfs in this regard.
One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. It's not a well supported feature and I feel that it's going outside of the core competancy for PyPI itself and instead PyPI should be focused on the files themselves. In addition since the time this was added to PyPI a number of free services or cheap services have came about that allow people to sanely upload raw document without a reliance on any particular documentation system and we've also had the rise of ReadTheDocs for when someone is using Sphinx as their documentation system.
I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas. The rough idea I have currently is to simply disable new documentation uploads and add two new small features. One will allow users to delete their existing documentation from PyPI and the other would allow them to register a redirect which would take them from the current location to wherever they move their documentation too. In order to prevent breaking documentation for projects which are defunct or not actively maintained we would maintain the archived documentation (sans what anyone has deleted) indefinetely.
Ideally I hope people start to use ReadTheDocs instead of PyPI itself. I think that ReadTheDocs is a great service with heavy ties to the Python community. They will do a better job at hosting documentation than PyPI ever could since that is their core goal. In addition there is a dialog between ReadTheDocs and PyPI where there is an opportunity to add integration between the two sites as well as features to ReadTheDocs that it currently lacks that people feel are a requirement before we move PyPI's documentation to read-only.
Thoughts?
* Out of ~60k projects only ~2.8k have ever uploaded documentation. It's not easy to tell if all of them are still using it as their primary source of documentation though or if it's old documentation that they just can't delete.
+1 for all the stated reasons.
I have a few docs hosted on pythonhosted.org, but it's become a nuisance to maintain since it does not support multiple doc versions like ReadTheDocs, so now I've wound up with documentation for the same projects on both sites. The nuisance comes not so much in the process (like Barry wrote, I've enjoyed the simplicity of `setup.py upload_docs`), but because more often than not I've had to redirect users to the Readthedocs docs to make sure they're using the correct version of the docs. So I wish I were not locked into updating the pythonhosted.org docs and would be happy to retire them altogether (much as I appreciated the service).
One question is how this would be handled at the tooling end. setup.py upload_docs would have to be retired somehow. Though it might also be nice if some simple tools were added to make it just as easy to add docs to ReadTheDocs. I know something like upload_docs doesn't really make sense, since RTD handles the checkout and build of the docs. But there's still a manual step of enabling new versions of the docs that it would be nice to make as effortless as `setup.py upload_docs`. I gues that's off-topic for the PyPI end of things though.
Erik
So I can’t speak for ReadTheDocs, but I believe that they are considering and/or are planning on offering arbitrary HTML uploads similarly to how you can upload documentation to PyPI. I don’t know if this will actually happen and what it would look like but I know they are thinking about it. As far as retiring upload_docs, the sanest thing to do I think would be to just have PyPI return an error code that upload_docs would display to the end user. The command itself is in use by a few other systems I think so we might not want to remove it wholesale from Python itself (or maybe we do? It’s a hard question since it’s tied to an external service unlike most of the stdlib). --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Le 2015-05-15 14:34, Donald Stufft a écrit :
As far as retiring upload_docs, the sanest thing to do I think would be to just have PyPI return an error code that upload_docs would display to the end user. The command itself is in use by a few other systems I think so we might not want to remove it wholesale from Python itself (or maybe we do? It’s a hard question since it’s tied to an external service unlike most of the stdlib).
upload_docs is implemented by setuptools, not distutils. Cheers
On 16 May 2015 at 04:34, Donald Stufft <donald@stufft.io> wrote:
So I can’t speak for ReadTheDocs, but I believe that they are considering and/or are planning on offering arbitrary HTML uploads similarly to how you can upload documentation to PyPI. I don’t know if this will actually happen and what it would look like but I know they are thinking about it.
I've never tried it with ReadTheDocs, but in theory the ".. raw:: html" docutils directive allows arbitrary HTML content to be embedded in a reStructuredText page. Regardless, "Can ReadTheDocs do X?" questions are better asked on https://groups.google.com/forum/#!forum/read-the-docs, while both GitHub and Atlassian (via BitBucket) offer free static HTML hosting. In relation to the original question, +1 for attempting to phase out PyPI's documentation hosting capability in favour of delegating to RTFD or third party static HTML hosting. One possible option to explore that minimises disruption for existing users might be to stop offering it to *new* projects, while allowing existing projects to continue uploading new versions of their documentation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On May 16, 2015 4:55 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 16 May 2015 at 04:34, Donald Stufft <donald@stufft.io> wrote:
So I can’t speak for ReadTheDocs, but I believe that they are
considering
and/or are planning on offering arbitrary HTML uploads similarly to how you can upload documentation to PyPI. I don’t know if this will actually happen and what it would look like but I know they are thinking about it.
I've never tried it with ReadTheDocs, but in theory the ".. raw:: html" docutils directive allows arbitrary HTML content to be embedded in a reStructuredText page.
Regardless, "Can ReadTheDocs do X?" questions are better asked on https://groups.google.com/forum/#!forum/ <https://groups.google.com/forum/#!forum/read-the-docs>read-the-docs <https://groups.google.com/forum/#!forum/read-the-docs>,
ReadTheDocs is hiring! https://blog.readthedocs.com/read-the-docs-is-hiring/
while both GitHub and Atlassian (via BitBucket) offer free static HTML hosting.
I just wrote a tool (pypi:pgs) for serving files over HTTP directly from gh-pages branches that works in conjunction with pypi:ghp-import (> gh-pages; touch .nojekyll). CloudFront DNS can sort of be used to add TLS/SSL to custom domains with GitHub Pages (and probably BitBucket)
In relation to the original question, +1 for attempting to phase out PyPI's documentation hosting capability in favour of delegating to RTFD or third party static HTML hosting. One possible option to explore that minimises disruption for existing users might be to stop offering it to *new* projects, while allowing existing projects to continue uploading new versions of their documentation.
- [ ] DOC: migration / alternatives guide
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Fri, 15 May 2015, at 15:48, Donald Stufft wrote:
Hey!
Hi Donald
Ideally I hope people start to use ReadTheDocs instead of PyPI itself.
+1. Do you want to use the python.org domain (ex. "pypi.python.org/docs") or keep RTD on it own domain? -- Sébastien Douche <seb@nmeos.net> Twitter: @sdouche http://douche.name
Ok, so unless someone comes out against this in the near future here are my plans: 1. Implement the ability to delete documentation. 2. Implement the ability to add a (simple) redirect where we would essentially just send /<project>/(.*) to $REDIRECT_BASE/$1. 3. Implement the ability to point the documentation URL to something that isn't pythonhosted.org 4. Send an email out to all projects that are currently utilizing the hosted documentation telling that it is going away, and give them links to RTD and GithubPages and whatever bitbucket calls their service. 5. Disable Documentation Uploads to PyPI with an error message that tells people the service has been discontinued. In addition to the above steps, we'll maintain any documentaton that doesn't get deleted (and the above redirects) indefinitely. Serving static read only documentation (other than deletes) is something that we can do without much trouble or cost. I think that this will cover all of the things that people in this thread have brought up as well as providing a sane migration path to go from pythonhosted.org documentation to wherever they choose to place their docs in the future. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Donald Stufft <donald@stufft.io> writes:
Ok, so unless someone comes out against this in the near future here are my plans:
1. Implement the ability to delete documentation.
+1.
2. Implement the ability to add a (simple) redirect where we would essentially just send /<project>/(.*) to $REDIRECT_BASE/$1.
3. Implement the ability to point the documentation URL to something that isn't pythonhosted.org
Both of these turn PyPI into a vector for arbitrary content, including (for example) illegal, misleading, or malicious content. Automatic redirects actively expose the visitor to any malicious or mistaken links set by the project owner. If you want to allow the documentation to be at some arbitrary location of the project owner's choice, then an explicit static link, which the visitor must click on (similar to the project home page link) is best. -- \ “I find the whole business of religion profoundly interesting. | `\ But it does mystify me that otherwise intelligent people take | _o__) it seriously.” —Douglas Adams | Ben Finney
On May 16, 2015, at 9:31 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Donald Stufft <donald@stufft.io> writes:
Ok, so unless someone comes out against this in the near future here are my plans:
1. Implement the ability to delete documentation.
+1.
2. Implement the ability to add a (simple) redirect where we would essentially just send /<project>/(.*) to $REDIRECT_BASE/$1.
3. Implement the ability to point the documentation URL to something that isn't pythonhosted.org
Both of these turn PyPI into a vector for arbitrary content, including (for example) illegal, misleading, or malicious content.
Automatic redirects actively expose the visitor to any malicious or mistaken links set by the project owner.
If you want to allow the documentation to be at some arbitrary location of the project owner's choice, then an explicit static link, which the visitor must click on (similar to the project home page link) is best.
To be clear, the documentation isn’t hosted on PyPI, it’s hosted on pythonhosted.org and we already allow people to upload arbitrary content to that domain, which can include JS based redirects. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 15 May 2015 at 23:48, Donald Stufft <donald@stufft.io> wrote:
I think that it's time to retire this aspect of PyPI which has never been well supported and instead focus on just the things that are core to PyPI. I don't have a fully concrete proposal for doing this, but I wanted to reach out here and figure out if anyone had any ideas.
Re-reading the current draft of PEP 470, it's worth noting we currently mention pythonhosted.org in as a means of hosting a separate index page for a project that would like to host packages externally: https://www.python.org/dev/peps/pep-0470/#deprecation-and-removal-of-link-sp... That's not a reason to avoid deprecating the documentation hosting functionality in favour of ReadTheDocs and static HTML hosting services, just something to take into account. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (11)
-
Barry Warsaw -
Ben Finney -
Daniel Holth -
Donald Stufft -
Erik Bray -
Ian Cordasco -
Jim Fulton -
Nick Coghlan -
Sébastien Douche -
Wes Turner -
Éric Araujo