[py-svn] r32976 - py/dist/py/documentation/apigen

[fijal at codespeak.net]

Author: fijal
Date: Sat Oct  7 07:53:35 2006
New Revision: 32976

Added:
   py/dist/py/documentation/apigen/roadmap.txt   (contents, props changed)
Log:
Added draft of roadmap.


Added: py/dist/py/documentation/apigen/roadmap.txt
==============================================================================
--- (empty file)
+++ py/dist/py/documentation/apigen/roadmap.txt	Sat Oct  7 07:53:35 2006
@@ -0,0 +1,102 @@
+
+Pylib roadmap, from my point of view
+====================================
+
+Author: Maciek Fijalkowski
+--------------------------
+
+Date: 7.X.2006
+
+Rough specifications of what needs to be done regarding py.test
+(especially distributed version), py.api and others.
+
+So main targets (for near future) of pylib developement would be:
+
+* further py.test distributed developement, especially incorporating
+  some command line options (I think -x and -k are done). This might be:
+  - options transfer to clients (maybe whole conftest) to allow them
+    to perform special things.
+  - -s (how???) --view for pypy, etc.
+  - screen/--pdb (there is some work done in this area)
+  - If someone (merlinux?) set up test farm (few machines connected
+    together for running tests), provide convenient interface for
+    running at least nightly tests (web one? offline html?) or even
+    just running tests for branch, trunk, custom svn without need to
+    upload local changes every time (RSync daemon?). I'm not sure if
+    it does make any sense, but makes convinient if we provide
+    front machine with access, not all the nodes (XXX and what with
+    screen?)
+  - Make sure web frontend works when more than one client (webbrowser)
+    connects to it (actually it does not).
+  - XXX: anything else?
+
+
+* integration from py.test distributed into normal py.test, especially
+  cool reporting features as well as web frontend (and extend it a bit)
+
+* benchmark integration into py.test. This issue haven't been discussed
+  in details. From my POV there should be done like running test in a
+  loop till having at least few seconds of run (some pypy tests takes
+  minutes to run, so this will not re-run the tests, but just take one),
+  than gather information and report it somehow. Should work as well
+  in distributed version (due to cool reporting, this might be the first
+  place to integrate). Various issues:
+  - Measure in MegaPystones or some other not-CPU-dependant units, so
+    we can compare results from different machines.
+
+PY.API:
+-------
+
+(actually lying down in py.test.tracer in branch, maybe not
+too nice name for that).
+
+Actual working version can provide simple ReST out of running very
+simple tests (functions only).
+
+So, todo list is (in random order):
+
+* Make interface for every possible single item on the end (function,
+  method, generator) to provide better coverage.
+
+* Make more... (frontend for API extraction, backend for output 
+  generation, different source link generators, etc. etc.)
+
+* Integrate it into py.test, as well as make possibility of gathering
+  this data from running process (this might allow to get it remotely
+  as well) with quite different tool (console/web, with possibility
+  to snapshot to static outcome).
+
+* Provide some model of determining which methods are exposed as API
+  and which are internal (just called directly in unittest looks like
+  enough for now, altough we do not have method of determining that yet)
+
+* Make clean vision of pypy annotation typesystem, probably even
+  extend it a bit (it's still easier to use than providing all
+  the interface on our own). Possible extensions:
+  - Provide SomeUnion instead of SomeObject which will behave like
+    gathering all possibilities together (this might be beneficient to
+    pypy as well).
+  - Provide some convinient way of getting common interface out of
+    objects that are contained in SomeObject. Like "what are the
+    common methods of both, even if they do not share a baseclass".
+    In this place, it should be quite easy to add different type
+    joining functions by user, because different projects might have
+    different needs at this point.
+
+* Test it on generating pylib documentation.
+
+* Make some API definition tool (object format) for defining API in
+  pypy. This will make a lot easier annotating the pypy source with
+  info (like "what the heck type comes here as an argument"....)
+
+Timeline:
+---------
+
+This is quite huge wishlist.... I don't know exactly what are priorities
+on all the stuff, what I would go first is to make API tool usable and
+easy to use as soon as possible, to show it at HHU on sprint in some
+running fashion. It should be well tested and maybe not containing
+all-the-possible features, but runnable.
+
+Next thing to do is to extend py.test distributed, especially with
+screen functionality.