-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
165 lines (164 loc) · 10 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
* See all TODO markings in source code
* Take a step back, reorganize. E.g.:
* stuff in `utils` should be user-useful only, other subroutines ought to go
elsewhere
* Should probably move subroutines in `main` to another module so that
`main` is just that: `main()`. New module would be something like `core` -
subroutines of the same sort found in `utils` but NOT usually for user
consumption (and ALSO not generally used multiple times by internals? or
should this be the same spot as other non-user-facing subroutines?)
* Also note that a number of main() subroutines right now, such as the
ones for finding settings, and setting host lists, should be updated so
that library users can use them!
* Re-examine API of existing operations, e.g. prompt's `validate` option
* wrt `validate`, figure out which is better: 'dual-mode' single arguments
like that, or splitting it into 2 different arguments
* dual-mode makes sense given an either-or situation like that one
* but at the same time it feels kind of messy
* see how stdlib does it in similar situations. guessing 2 arguments
with "only X or Y may be given, but not both at the same time" note?
* look at the rest too
* Output handling -- how to deal with:
* Status info
* Warnings
* Errors/failures (both printing info, and how to abort or not abort flow)
* Also provide easy access to the return code, regardless of whether
Fabric actually fails -- i.e. have some level where the user can
inspect return codes and decide on their own whether to abort() or what
* Exceptions (outside of the ones involved with errors/failures)
* As mentioned elsewhere, want to make this as flexible as possible
* Put in logging-to-disk and/or leverage the logging module for stdout too?
* e.g. it already has the concepts of info/warn/etc -- can that be used?
* Ensure things behave gracefully when used as a lib
* Temporarily had 'invoked_as_fab' env var set in main(); but that made
testing a huge pain, so backed it out. Put it back in? or find some
other method? perhaps inverse -- setting has to be turned on
explicitly by a library user? or just ensure that e.g. printing,
exceptions have simple controls for making them shut up?
* Regardless of other work in this area, make sure `local` can be
configured to print its output without being wrapped in `print` (durr)
* Continue building out any previously made tests till coverage.py implies we
have pretty decent coverage (100% would be nice but even a 100% from coverage.py
doesn't literally mean full coverage...)
* Have started using Nose for testing, probably stick with that;
* Ditto with Fudge for mocking/stubbing/expecting; may need to contribute
some patches to it, though, it's not great for functional coding and I
don't see the need to 100% class-ify my code just so my mocker works better.
* Sphinx documentation
* Functions wrapped with the @needs_host decorator, due to how @wraps works,
lose their argument signature because the wrapping function has to define the
generic signature (so it can take any input). Thus, since there doesn't seem
to be a way around this (I looked) I will need to add ``autofunction``
directives and repeat the signature.
* Might be wise to update build_docs so it scans for that sort of thing
and checks it against the actual signatures using the ``inspect``
module, e.g. ``printargspec(getargspec(function))``.
* In fact, even better might be for build_docs to just use that to
**generate** the autofunction directives for me. Hmm.
* Update all docstrings so they "read well" in the generated API:
* General language / tense / etc
* Where applicable, turn ``function()`` into `function` (so the default
role takes effect and makes it a link)
* If that default role doesn't work right for non-functions, add the
appropriate :type: prefixes.
* Go over old static docs to make sure anything applicable is copied over
and updated.
* Don't forget the top level text files, e.g. INSTALL
* Run Pylint, fix what it complains about (and generate a config file to make it
shut up about stuff I don't care about)
* Make sure "constants" are consistently named: I've been trending towards not
using ALL_CAPS, but in some places I probably did use them, so check and
update (or change my mind and go back; but it just feels ugly when one is
referencing e.g. ENV in user code all over...)
* Possibly note in docs that callables imported into one's fabfile will show up
as executable tasks; i.e. they'll clutter --list and can be invoked via
command-line.
* If we do note this for users, probably suggest the obvious: import
modules instead of callables, and use module.callable instead.
* Also good to note that they can take *advantage* of this to make
"meta-fabfiles" collecting a number of sub-fabfiles' tasks into one
user-facing presentation.
* Although, with flags for manually specifying 1+ sub-fabfiles at
runtime, that becomes less necessary, though still useful.
* Add with_sudo option to put(), which would need to be implemented as a call
to itself (or make an inner function?) followed by a sudo mv call.
* Terminology: rename 'commands' to 'tasks', 'operations' to 'commands' or
'functions' or something?
* Plus: 'tasks' and etc sounds more natural to me; given how big of a
shake-up this is, why not go whole hog?
* Minus: commands/operations aren't all that bad for names, and should
avoid tendency to redo everything for redoing's sake.
* Minus: 'commands' feels like the most natural fit for a rename of
'operations' -- but then it's pretty confusing given the previous use of
'commands'!
* Add Paramiko SSHConfig support: it can provide username and port and other
options. Look at `man ssh_config` for what else people can put in that file.
* Try to make Fabric threadsafe (and/or not using threads for outputting)
* Right now it uses threads and shared state for outputting, and shared
state for env/connection/etc stuff. This is probably not threadsafe as-is.
* Even if the shared state works OK, the thread use in outputting is kind
of wonky. See if it can be redone with coroutines or Twisted or something.
* Make execution model more robust/flexible:
* Right now, relatively simple, calls each function one by one, and for each
function, runs on each host one by one, and the host list may be different
per-function.
* What may make more sense is to specify host list "first", then for each
host, you call each function in turn (in which case the order of functions
may matter more than it does now). This would mean that the logic for host
discovery changes a decent amount.
* Do we want to allow this to be switched up dynamically? I.e. allow user
to specify a "mode" (like in the old Fabric) to determine which of those
two algorithms is used?
* How do these decisions affect what decorators/etc can be applied? I.e.
@hosts doesn't make any sense in the latter scenario because there is only
one global host list per session. (But isn't that the more sensible
solution? When would you execute a `fab` command line and expect the host
list to change during the session?
* Possibly add back in the old `shell` functionality (it would have to be a
command line option such as `--run-shell` -- there are no more internal
"commands" and it doesn't make sense as one anyway, as it cannot be run along
with other commands at the same time.)
* Probably leverage IPython as a library, I've seen it done before
* Should end up equivalent to a user running `ipython` and then doing a
bunch of typical Fabric imports, i.e. all the operations plus `env`.
* Check Python 2.6 compatibility.
* Bash tab-completion for Fab tasks, assuming it can be done without being too
laggy.
* Possibly allow "aliases" in `env`, i.e. 'user' and 'username' treated as
being the same key to limit possible confusion.
* Investigate allowing control of pty allocation for remote connections (look at
emails for previous discussion)
* Try using `/usr/bin/env bash` instead of `/bin/bash` to handle systems where
bash isn't in `/bin/`?
* Parallel execution (if it can be done without making things terribly complex
again)
* Better remote-end prompt detection/passthrough to local user
* Add timeout support or ensure existing network level timeouts work well
* More robust per-host/connection settings, e.g. dict of dicts or registry or
some such.
* Possibly include path.py support (or rather use some of its concepts, since
I think it only works on local paths as-is?)
* Allow persistent environments, either real (run a bunch of commands in one
command string) or fake (put a prefix with e.g. 'cd foo && ' in front of each
shell invocation, behind the scenes)
* Strip ANSI colors from remote text, as an option (so I can stop having to do
ls --color=never and so on)
* Provide combined env-setting context manager that replaces or at least
augments existing ones like `warnings_only`, e.g. `with_env(key1=val1,
key2=val2)`. As with `warnings_only` it should restore the previous settings in
its exit block.
* This would thus prevent a bunch of ugly nesting when wanting to use >1
context manager at once; and since behavior is always controlled with env
vars, it should be able to handle just about anything.
* Consider truncating the docstring part of --list output, instead of wrapping?
* Consider automatically detecting "missing" args to tasks and prompting for
them?
* Refactor run/sudo:
* many times I want to run a handful of commands as one or the other, or
there are call chains (e.g. in contrib and the fabfile) where I have to pass
`use_sudo` all the way down, and so on.
* run/sudo are nearly identical except for a handful of lines, so they
violate DRY.
* Probably do the usual "behavior controlled via `env`" thing, and make the
usual context manager too?
<!-- vim:set filetype=mkd : -->