[py-svn] r33178 - in py/dist/py/documentation: . apigen
fijal at codespeak.net
fijal at codespeak.net
Wed Oct 11 19:10:24 CEST 2006
Author: fijal
Date: Wed Oct 11 19:10:22 2006
New Revision: 33178
Added:
py/dist/py/documentation/roadmap.txt
- copied unchanged from r33177, py/dist/py/documentation/apigen/roadmap.txt
Removed:
py/dist/py/documentation/apigen/roadmap.txt
Log:
Moved to more apropriate place.
Deleted: /py/dist/py/documentation/apigen/roadmap.txt
==============================================================================
--- /py/dist/py/documentation/apigen/roadmap.txt Wed Oct 11 19:10:22 2006
+++ (empty file)
@@ -1,99 +0,0 @@
-
-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:
-
- - DONE 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)
-
-* integrate some kind of TestRunner, which will run the tests and perform
- some additional stuff. This is related to (but not limited):
-
- - benchmarks
-
- - py.api integration
-
-PY.API:
--------
-
-(actually lying down in py.test.tracer in branch, maybe not
-too nice name for that, will go to py.api).
-
-So, todo list is (in random order):
-
-* Make interface for every possible single item on the end (function,
- method, generator) to provide better coverage. Function/method DONE.
-
-* Make more... (frontend for API extraction, backend for output
- generation, different source link generators, etc. etc.)
-
-* 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)
-
-* Provide some command line debugger-like tool (PDB hook?) which will expose
- API information additionally to debugging info.
-
-* 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"....)
-
-* Add several different things to trace, mostly tracing of side effects
- (track what method can change what attributes, as well as in child nodes.
- Maybe global variables as well).
-
-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.
More information about the pytest-commit
mailing list