Use the python logging module under the hood for bb.msg
[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 - Convert bb modules to stop using the bb.msg functions.
21 - Switch the messaging wrappers in the bb package to use the logging module
22   directly, as we'll be deprecating the bb.msg versions, but these should
23   stay around for the metadata to use.
24 - Deprecate the bb.msg functions.
25 - Should we use the logging module rather than print in the knotty ui?
26
27 Long term, high impact:
28
29   - Change override application to actually *move* it over -- so the original
30     override specific version of the variable goes away, rather than sticking
31     around as a duplicate.
32   - Change the behavior when a variable is referenced and is unset.  Today, it
33     evaluates to ${FOO} and then shell has a chance to expand it, but this is
34     far from ideal.  We had considered evaluating it to the empty string, but
35     that has other potential problems.  Frans Meulenbroeks has proposed just
36     erroring when this occurs, as we can always define default values for the
37     variables in bitbake.conf.  This seems reasonable.  My only concern with
38     that is the case where you want to reference a shell variable with odd
39     characters in it -- where you'd have to use ${} style shell variable
40     expansion rather than normal $.  To handle that case, we'd really need a
41     way to escape / disable bitbake variable expansion, \${} perhaps.
42
43 Uncertain:
44
45   - Leverage the python 2.6 multiprocessing module
46
47     - Worker processes for bb.cooker
48     - Server / UI processes
49
50   - Create a bitbake configuration class which is utilized by the library, not
51     just bin/bitbake.  This class should be responsible for extracting
52     configuration parameters from the metadata for bitbake internal use, as well
53     as pulling specific items like BBDEBUG, and importing settings from an
54     optparse options object.
55
56   - Python version bits
57
58     - Utilize the new string formatting where appropriate
59     - Do we need to take into account the bytes literals changes?
60     - Do we have any file-like objects that would benefit from using the "io"
61       module?
62     - Do we want to leverage the abstract base classes in collections?
63     - Aside: Set methods now accept multiple iterables