[py-dev] Re: [pypy-dev] utest, development and discussion
Laura Creighton wrote:
Anyway, I've started working with it some. I've added one small feature (dropping into pdb when an exception occurs), and there's sure to be some more, particularly documentation. Where should I send patches? Where should discussion occur? And maybe a website?
Discussion belongs here. Patches too unless you want to get a project login, a process that Holger handles. There isn't a separate part of the pypy wiki - or the website for utest. Probably that should change. And documentation belongs here: http://codespeak.net/pypy/index.cgi?doc which we generate out of files in pypy/trunk/doc . You write your docs in ReST and a daemon comes along and makes html out of them for you.
Since std (I guess to be named py) isn't under pypy, I assume documentation should go in std/trunk/doc? Can it be set up that this is also turned into HTML? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
[Ian Bicking Wed, Sep 29, 2004 at 07:46:45PM -0500]
Laura Creighton wrote:
Anyway, I've started working with it some. I've added one small feature (dropping into pdb when an exception occurs), and there's sure to be some more, particularly documentation. Where should I send patches? Where should discussion occur? And maybe a website?
Discussion belongs here. Patches too unless you want to get a project login, a process that Holger handles. There isn't a separate part of the pypy wiki - or the website for utest. Probably that should change. And documentation belongs here: http://codespeak.net/pypy/index.cgi?doc which we generate out of files in pypy/trunk/doc . You write your docs in ReST and a daemon comes along and makes html out of them for you.
Since std (I guess to be named py) isn't under pypy, I assume documentation should go in std/trunk/doc? Can it be set up that this is also turned into HTML?
yes, this is certainly possible although some of the html generation is loosely tied to pypy. however, i want std/py is to be the first project which will be hosted by 'trac' on the new codespeak setup. holger
holger krekel wrote:
Since std (I guess to be named py) isn't under pypy, I assume documentation should go in std/trunk/doc? Can it be set up that this is also turned into HTML?
yes, this is certainly possible although some of the html generation is loosely tied to pypy.
however, i want std/py is to be the first project which will be hosted by 'trac' on the new codespeak setup.
Will the documentation still be in ReST, or will it use another Wiki-ish markup? I was going to try to write some basic documentation (well, maybe this weekend), with whatever vague sense I have of how things work, and I just wanted to put it in the right place and format. And utest is a good test runner right now, I think documentation is the only thing that would keep people from using it. Well, a distutil setup or something equivalent that would also be helpful. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
[Ian Bicking Thu, Sep 30, 2004 at 08:24:43PM -0500]
holger krekel wrote:
Since std (I guess to be named py) isn't under pypy, I assume documentation should go in std/trunk/doc? Can it be set up that this is also turned into HTML?
yes, this is certainly possible although some of the html generation is loosely tied to pypy.
however, i want std/py is to be the first project which will be hosted by 'trac' on the new codespeak setup.
Will the documentation still be in ReST, or will it use another Wiki-ish markup? I was going to try to write some basic documentation (well, maybe this weekend), with whatever vague sense I have of how things work, and I just wanted to put it in the right place and format. And utest is a good test runner right now, I think documentation is the only thing that would keep people from using it. Well, a distutil setup or something equivalent that would also be helpful.
Right on all points. I guess that with test runner you also refer to the collection/running distinction. Actually ReST is probably good for "static" reliable documentation that comes with the package and wiki-ish stuff for all kinds of more dynamic/experimental/example stuff that has a high probability of changing. Of course, a simple distutils setup install wouldn't be a problem. But somehow i have this idea that i want to make it easy for people to upgrade to a newer version of the py lib and i haven't quite figured out how to do it. That how it is with me: i always try to fix other stuff before continuing to fix the current code at hand and this is a recursive process. Now maybe just more people need to start doing it or, more likely the right answer, i need to become more pragmatic :-) cheers, holger
participants (3)
-
holger krekel -
hpk＠trillke.net
-
Ian Bicking