Until the interactive mode is fixed, kill it from the valid options, to avoid confusion
[bitbake.git] / TODO
1 - Reimplement the interactive mode as a proper ui
2 - Move the LAYERDIR expansion hack into DataSmart, as that's where code that
3   depends upon its internals belongs
4 - Continue dropping fatal/SystemExit/sys.exit usage in favor of raising
5   appropriate exceptions
6 - Continue pylint / pyflakes / pychecker / pep8 fixups
7 - Drop os.system usage in favor of direct subprocess usage or a subprocess
8   wrapper
9 - Kill the execution of 'tee' for the task log file in build.py
10 - Fix up the exception handling
11
12   - Kill exec_task's catch of FuncFailed, instead catch it in the other
13     callers of exec_task/exec_func
14   - What exactly is the purpose of the "EventException"?  I can see using an
15     exception like that, *perhaps*, to abstract away exceptions raised by
16     event handlers, but it has no place in bb.build.exec_task
17
18 - Leverage the python logging module
19
20   - Create a new logging Handler which instantiates MsgBase derived objects
21     and passes them along, either via bb.event or directly over the
22     appropriate queues to the other processes.
23   - Alter the bb.msg functions to use the logging module.
24   - Convert bb modules to stop using the bb.msg functions.
25   - Switch the messaging wrappers in the bb package to use the logging module
26     directly, as we'll be deprecating the bb.msg versions, but these should
27     stay around for the metadata to use.
28   - Deprecate the bb.msg functions.
29   - Do we want to use the logging module in any of the UIs, for local
30     messages, as well?  If we do, we don't want those to use our handler which
31     sends the Msg events to the UI :)
32     Looks like we may be able to use removeHandler.. will have to see how it
33     interacts with parent/child loggers.
34
35 Uncertain:
36
37   - Leverage the python 2.6 multiprocessing module
38
39     - Worker processes for bb.cooker
40     - Server / UI processes
41
42   - Create a bitbake configuration class which is utilized by the library, not
43     just bin/bitbake.  This class should be responsible for extracting
44     configuration parameters from the metadata for bitbake internal use, as well
45     as pulling specific items like BBDEBUG, and importing settings from an
46     optparse options object.
47
48   - Python version bits
49
50     - Utilize the new string formatting where appropriate
51     - Do we need to take into account the bytes literals changes?
52     - Do we have any file-like objects that would benefit from using the "io"
53       module?
54     - Do we want to leverage the abstract base classes in collections?
55     - Aside: Set methods now accept multiple iterables