[yt-dev] Best place for planning documentation?

Matthew Turk matthewturk at gmail.com
Mon Nov 19 08:22:04 PST 2012


Hmm, it looks to me like they tried using ReadTheDocs in the past, but
that it hasn't built in a while.

We might be able to use mocking:

http://blog.rtwilson.com/how-to-make-your-sphinx-documentation-compile-with-readthedocs-when-youre-using-numpy-and-scipy/

but I'm not sure.

On Mon, Nov 19, 2012 at 11:19 AM, Casey W. Stark <caseywstark at gmail.com> wrote:
> Does anyone happen to know how numpy/scipy handle this? It looks like they
> autodoc as well and must have coordinated this in the past.
>
> - Casey
>
>
> On Mon, Nov 19, 2012 at 8:16 AM, Britton Smith <brittonsmith at gmail.com>
> wrote:
>>
>> Maybe the simplest solution for now is for more people to have privileges
>> to rebuild the docs.  Then, it can be the responsibility of the last person
>> to push a change to do it.  Every other solution seems like more work than
>> anyone has time to put in right now.
>>
>> Britton
>>
>>
>>
>> On Mon, Nov 19, 2012 at 11:12 AM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>>>
>>> On Mon, Nov 19, 2012 at 11:09 AM, Stephen Skory <s at skory.us> wrote:
>>> >> Confluence is the slickest, and the Wiki in the past has gone out of
>>> >> date relatively quickly.  Any strong feelings on which I should start
>>> >> using as a dumping ground for information about 3.0 vs 2.x?
>>> >
>>> > I hate to inflict pain, but I really think that sphinx/yt-doc is the
>>> > way to go. I think having diverging documentation trees is going to
>>> > cause more pain in the long run. Is there no way to automate the
>>> > (re)building of the sphinx docs (not the default public ones, of
>>> > course)?
>>>
>>> The problem with rebuilding the sphinx documentation is that since it
>>> relies on introspection of a running yt session to do the automodule /
>>> autofunction documentation, we can't use solutions like ReadTheDocs.
>>> In principle, we could use ShiningPanda, but since it takes ten to
>>> fifteen minutes to build yt-doc, this could run out of credits
>>> quickly.  If you wanted to take on the project of migrating our entire
>>> hosting system to Amazon S3, we could probably make it work.  As it
>>> stands, the only non-dynamic content yt has is the pastebin.  That
>>> would have to stay at dreamhost for now, but we could move the main
>>> page, the docs, and so on, over to S3.
>>>
>>> So I think yes, it could be done, but I'm not willing to do it; I'm
>>> more than happy to turn this over to someone else, though.  And it's
>>> not clear to me that it would meet the need of an evolving design
>>> specification where multiple contributors commented; it would only
>>> meet the need of a single designer, which I don't think is necessarily
>>> the right solution.
>>>
>>> -Matt
>>>
>>> >
>>> > --
>>> > Stephen Skory
>>> > s at skory.us
>>> > http://stephenskory.com/
>>> > 510.621.3687 (google voice)
>>> > _______________________________________________
>>> > yt-dev mailing list
>>> > yt-dev at lists.spacepope.org
>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list