<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 5, 2016 at 6:33 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><p dir="ltr"><br>
On 4 Jun 2016 6:54 am, "Donald Stufft" <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>> wrote:<br>
><br>
><br>
>> On Jun 4, 2016, at 9:33 AM, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
>><br>
>> I think everyone would agree that having some nice doc hosting service available as an option would be, well, nice. Everyone likes options. But the current doc hosting is unpopular and feature poor, falls outside of the PyPI core mission, and is redundant with other more popular services, at a time when the PyPI developers are struggling to maintain core services.<br>
><br>
><br>
><br>
> To add to what Nathaniel said here, there are a few problems with the current situation:<br>
><br>
> Documentation hosting largely worked “OK” when it was just writing files out to disk, however we’ve since removed all use of the local disk (so that we can scale past 1 machine) and we’re now storing things in S3. This makes documentation hosting particularly expensive in terms of API calls because we need to do expensive list key operations to discover which files exist (versus package files where we have a database full of files).</p>
</span><p dir="ltr">Amazon do offer higher level alternatives like <a href="https://aws.amazon.com/efs/" target="_blank">https://aws.amazon.com/efs/</a> for use cases like PyPI's docs hosting that assume they have access to a normal filesystem.</p>
<p dir="ltr">Given the credential management benefits of integrated docs, </p></blockquote><div>From the RTD blog post linked by Nathaniel: <br>""<br>Our proposed grant, for $48,000, is to build a separate instance that integrates
with the Python Package Index’s upcoming website, <a href="https://warehouse.python.org/" target="_blank">Warehouse</a>. This integration
will provide automatic API reference documentation upon package release, with
authentication tied to PyPI and simple configuration inside the distribution.<br>"" <br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">it does seem worthwhile to me for the PSF to invest in a lowest common denominator static file hosting capability, </p></blockquote><div>Seems like a very poor way to spend money and developer time imho. The original post by Jason brings up a few shortcomings of RTD, but I'm amazed that that leads multiple people here to conclude that starting a new doc hosting effort is the right answer to that. The much better alternative is: read the RTD contributing guide [1] and their plans for PyPI integration [2], then start helping out with adding those features to RTD. <br></div><br></div><div class="gmail_quote">There is very little chance that a new effort as discussed here can come close to RTD, which is a quite active project with by now over 200 contributors. Starting a new project should be done for the right reasons: existing projects don't have and don't want to implement features you need, you have a better technical design, you want to reimplement to learn from it, etc. There are no such reasons here as far as I can tell.<br><br></div><div class="gmail_quote">If there's money left for packaging related work, I'm sure we can think of better ways to spend it. First thoughts:<br></div><div class="gmail_quote">- Accelerate PyPI integration plans for RTD<br></div><div class="gmail_quote">- Accelerate work on Warehouse<br></div><div class="gmail_quote">- Pay someone to review and merge distutils patches in the Python bug tracker<br></div><div class="gmail_quote"><br><br></div><div class="gmail_quote">Final thought: there's nothing wrong with distributed infrastructure for projects. A typical project today may have code hosting on GitHub or Bitbucket, use multiple CI providers in parallel, use a separate code coverage service, upload releases to PyPI, conda-forge and GitHub Releases, and host docs on RTD. Integrating doc hosting with PyPI doesn't change that picture really.<br></div><div class="gmail_quote"><br>Ralf<br><br>[1] <a href="https://github.com/rtfd/readthedocs.org/blob/master/docs/contribute.rst" target="_blank">https://github.com/rtfd/readthedocs.org/blob/master/docs/contribute.rst</a><br>[2] <a href="https://github.com/rtfd/readthedocs.org/issues/1957" target="_blank">https://github.com/rtfd/readthedocs.org/issues/1957</a><br><br></div><br></div></div>