Activity
From 12/14/2009 to 01/12/2010
01/12/2010
-
01:31 PM Feature #134: Allow --list (or another option) to filter listed tasks
- When using large fabfiles, one may wish to search for or filter task names. E.g. you know you have some relating to Python but aren't entirely sure and want to do something like `fab --list "py*"`. Benefit of adding this to `-l`/`--list` is tha...
01/11/2010
-
12:22 AM Feature #98: Optionally avoid using ssh if going to localhost
- I've just implemented something similar this evening in the form of a new fabric.operations function called `do`. It looks at `env.run_as` to see if it equals "local", and in doing so switches out to the `local` method instead of the `run` (or `s...
01/09/2010
-
- Might be nice to provide support for pre/post hooks, so that one can specify code to run before and/or after their tasks are executed. E.g. for long-running tasks, users may want emails to be sent out notifying that things worked (or didn't; wh...
-
01/08/2010
-
11:30 PM Bug #132: run()/sudo() strip the output, local() does not
- Just a little inconsistency that can be surprising: I ran run('mktemp') and was able to use the output directly, local('mktemp') caused me all sorts of problems with the trailing newline until I realized what was going on. Fixed [here](http://g...
-
- Merge branch '0.9'
-
- Fix incorrect statement in upgrade docs
-
- E.g. say you wish to connect to a large series of hosts but a handful of them are temporarily down or unreachable, or are "bad" (i.e. don't have SSH, or your intended user doesn't exist on them, etc.) Right now Fabric will just explode if it canno...
01/06/2010
-
- Hey guys, note: updates to this ticket (or any ticket with a watcher who's got Unicode chars in the name -- hi Domen!) do seem to trigger 500s -- but that 500 only occurs at the "alert watchers" step. So comments and so forth do get stored in the ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Add reboot() to API
-
- IRC is a crapshoot, I idle in there all the time but whether I'm actually "there" and listening is kind of random :) I had missed your note until about 3 hours later, I think. So yea -- Redmine is the ticket. (ho ho! get it?)
-
- Jeff Forcier wrote: > Also, note -- leaving a ticket here is fine, no need to also send a GH pull request, it's just 2x the emails/messages for me to handle ;) Yeah. And I also piped up in IRC for the trifecta :-) Just not sure which was the p...
01/05/2010
-
- Thanks for the catch -- as usual, the first implementation of stuff tends to be relatively naive. Your point is a good one. Will fix / pull down your tweak in the near future. Thanks again! Also, note -- leaving a ticket here is fine, no nee...
-
- In general, Fabric's context managers fail to clean up after themselves in case an exception is raised within them. This makes it difficult to use them if you're trying to do exception handling. For instance, take the following code: try: ...
-
- If you want to reattach this to #6, it can go in with another couple of ideas/links I had in there. I reckon yours is probably similar to the one linked on Github, but I'll double check when I have time to look at that ticket :) Thanks for the ...
-
06:19 PM Feature #129: Bash-completion script
- Hey there, I wrote a Bash completion script for Fabric. Completion suggestions are generated dynamically from the `fab -l` output. Do you have any use for this? Arthur
-
- @Jeff: Thanks. The design idea just hit me the other day and only took 30 or 45 minutes to implement with tests once I settled on it. Regarding the plain import vs. import/register, I'm ambivalent. I don't particularly care for having to use ...
01/03/2010
-
- Add disconnect_all to 1.0 changelog
-
- Docs for previous commit (disconnect_all)
-
- Break out disconnect code into network function. Needed for library users to successfully terminate their code; otherwise their scripts will never exit as the SSH connections stay open and prevent termination.
-
- Jeff B indicated via IRC that this is indeed an edge case, so I'll close it for now.
-
- Oh, and you could also make a temporary directory instead of temporary file, and place your temp fabfile in there. That way when the temp dir is removed, both the py and pyc would get nuked. (I may still add the feature, but it does feel like a bi...
-
- Sounds fair enough. Were you aware of the `sys.dont_write_bytecode` aspect of that 2.6 feature which I appended to the description? Depending on how you're creating these temporary fabfiles, and assuming you're using Fabric as a library instead of...
-
05:54 AM Feature #128: dont_write_bytecode env var
- I'm creating on-the-fly fab files with NamedTemporaryFile for building EC2 images. When execution is finished, the temporary files are automatically deleted, but the compiled .pyc files remain behind.
01/02/2010
-
- To sate my curiosity, what situations are you running into where .pyc files are causing a problem? First time I've heard of this outside of the occasional stale-pyc issues I used to get with mod_python. It looks like this is a pretty easy thing...
-
01:37 PM Feature #56: Add namespacing or dot notation
- I would propose more Pythonic version: - Create **fabric.plugins** setuptools namespace (or [[http://docs.python.org/dev/library/pkgutil.html?highlight=pkgutil#pkgutil.extend_path]]) - let users contribute to that namespace, so contributed f...
-
- There are situations where you don't want to leave **.pyc** files around after execution. A current workaround is to do something like this: `PYTHONDONTWRITEBYTECODE=True fab -f myfab.py` But it would be nicer to handle this explicitly in a...
-
- (Note: I got what was probably the same error you got. Looks like a bug in `acts_as_watchable`; will double check your errors later when I have more time. But you're not crazy! :))
-
- (Nuked the "spam" comments -- note, I do it by editing and just removing all text; Redmine seems to treat that as a deletion and removes the comment. Pretty sure you can edit your own comments, give it a try sometime. Will make a note to look in m...
01/01/2010
-
02:08 PM Bug #84: fabric.contrib.files.sed uses "non-standard" flag '-r'
- In FreeBSD I have the same problem: Bad example: [root@192.168.1.20] run: sed -i.bak -r -e 's/host \*/host 192.168.1.20/g' /usr/local/etc/munin/munin-node.conf [root@192.168.1.20] err: sed: illegal option -- r [root@192.168.1.2...
12/30/2009
-
- I just [added support][patch] for this in a slightly different manner over in [my fork][fork]. My solution was to add a `FABRIC_TASK_MODULE` variable, and when that's not False, include those values in the list you build up. Fabric's current tas...
-
- Yet another thought -- might be better to just search upwards in the file root instead of stopping like we do now. This is closer to what some of the users asked for, and is also a bit cleaner than the more arbitrary "home-dir fabfile plus first l...
-
- OK, enough modifying the description, time for a comment thread... Had another thought -- if this goes through we should also update `-f`/`--fabfile` to be specifiable more than once, probably the best way to expose the new "multiple fabfile" i...
12/27/2009
-
10:39 PM Support #127: Add PyPM to the installation document
- Since the Windows installation scenario is [not always smooth](http://stackoverflow.com/questions/1917193/installing-fabric-on-windows-error-no-module-called-readline), it would be nice to include a note about PyPM in the fabric installation docum...
12/23/2009
-
- That's true, we could implement both. I'm on the fence about doing so, because I want to avoid falling into the trap of having too many choices/features (simpler is better) but it *would* be nice to offer `__all__` since it's quite Pythonic and wo...
12/22/2009
-
- Doh - missed this when I searched for a duplicate before adding. I like the decorator method as well and wouldn't consider the two at odds with each other, but they would require an order of priority. Off the cuff, I'm thinking `__all__` (as i...
-
- Thanks for making the ticket, and answering my query about implementation, it's appreciated. Your logic makes sense; offhand I also think I do prefer the approach of having just `write` with `append` being a call to `write(<arguments>, overwrite=F...
-
- Travis Swicegood took an independent stab at implementing the `__all__` approach, so if we do end up going that route (still think decorators are marginally better, myself) it can be found on [his github fork @9fdb4a3](http://github.com/tswicegood...
-
-
- This feature and tests for load_fabfile() are already completed in [9fdb4a3][] of my [fork][]. [9fdb4a3]: http://github.com/tswicegood/fabric/commit/9fdb4a39235365e1d9f54a788a69480c9cde030d [fork]: http://github.com/tswicegood/fabric/
-
- Currently, all functions that do not begin with `_` are considered tasks within Fabric. This exposes any helper functions as full tasks, though they may not work in isolation. One solution to this is to utilize Python's built-in `__all__` valu...
-
- I've added this support to [my fork][fork] of Fabric in commit [cc853f1][]. It adds two new commands, `write()` (the one that would normally be used) and a generic command `write_to_file()` which takes the optional `overwrite=False` keyword argum...
-
- contrib.files.append allows adding to a file, but it doesn't support overwriting a file. Sometimes you need to be able to just write to a file, regardless of what is there already. The put() command is often useful in such cases, but it doesn't ...
-
- [tswicegood's fork](http://github.com/tswicegood/fabric/commit/9aee3612beb27a838500be949a3940b963df4dc8), like another older (and since deleted) fork, includes the single-to-double quote change in the files module. At the very least, check with hi...
-
- See also some semi-related work in [tswicegood's fork](http://github.com/tswicegood/fabric/commits/master)
-
- Nose ships with [a stdout-capturing plugin](http://somethingaboutorange.com/mrl/projects/nose/0.11.1/plugins/capture.html) which may be useful. Doesn't say anything about stderr, though, which I think some tests need to look at, but double check.
12/19/2009
-
- Massive overhaul of description.
12/18/2009
-
- Fix embarrassing mistake in previous changeset. Re #23 -- first-draft of feature wasn't working with cd() correctly. Now it does.
-
- Great, and thanks for taking the time to troubleshoot all this.
-
03:25 PM Bug #123: ImportError in _get_system_username on cyqwin without win32api installed
- I am currently setting up a project which will be utilizing fabric. I have removed the 'cygwin' item from win32 = sys.platform in ['win32', 'cygwin']. Once I get the project set up and running I will report back with updates on how things are wo...
-
- both work on my systems (vista and XP with cygwin) ...
-
- I see, it's been a while so I forgot that we check for cygwin as well. So you're saying that recent Pythons that come with Cygwin have a working os.getlogin() method, then? Could you test out the other few spots in the code where we make use of...
12/17/2009
-
- well I use cygwin on windows and do not have win32 stuff installed and can't run fabric without it. Either is should be on the dependency list or break out cygwin as a different state. If I remove 'cygwin' from the list (win32 = os.platform in...
-
- Well it seems to work under cygwin on vista and xp for me. Also the current "not win32" works as well.  I will do some ...
-
- Have you actually tried using `os.getlogin` on Windows? According to the Python docs, it's a Unix-only operation, which (I imagine) is why all username/homedir patches I've received have made use of `win32api`. Let me know -- I don't test or de...
-
- this should work instead import os return os.getlogin()
-
- here is the trace /usr/lib/python2.5/site-packages/fabric/state.py in _get_system_username() 72 return pwd.getpwuid(os.getuid())[0] 73 else: ---> 74 import win32api 75 import win32security ...
-
- function _get_system_username() fails when using cygwin without win32api installed. ` /usr/lib/python2.5/site-packages/fabric/state.py in _get_system_username() 72 return pwd.getpwuid(os.getuid())[0] 73 else: ---> 74...
-
02:06 PM Feature #21: Make execution model more robust/flexible
- http://github.com/andymccurdy/fabric/tree/class-based-tasks Initial stab at class-based tasks. Tests pass. Probably want to accept more named parameters on in Task.__init__, like hosts, roles, etc which could alter the environment prior to runn...
12/16/2009
-
- Expansion of docstring for new prefix contextmanager.
-
- First draft of new prefix context manager. Re #23.
12/15/2009
-
- Yes, right now fabricrc is stupid-simple and only lets you store strings, so it's not a great fit for hosts. Splitting on commas might do the trick, I'll have to think about it. The rcfile really just needs a serious update, such as making it a...
-
07:55 PM Feature #122: Allow fabricrc to be fabfile-esque Python module?
- EDIT: updated subject to reflect another couple of users on the ML wanting basically the same thing -- ability to have more powerful user-specific settings and tasks -- basically an additional fabfile. I think the best forward-looking approach ...
-
- * Current behavior, based on patch from alisaifee, is to automatically try and force the remote file to match the mode of the local file. (Probably added to aid in preserving specific masks like +x or g+w when uploading files new to the remote end...
12/14/2009
-
- Add @task decorator for explicit marking of tasks. Re #76. Still needs docs, tests. Should also expand on this to allow easier extension of "detection" algorithm(s), as per branch name :)
-
- Copy-n-paste of IRC discussion between myself and Andy follows below (wrapped to not break layout.) No real decisions were reached, just some back and forth about pros/cons. It's still clear that classes are powerful and can be used to implemen...
-
- Only open question so far is how to handle private-but-marked tasks (which, yes, is one of the reasons I just rejected `__all__` above...meh) but for now, since explicit marking is, well, explicit -- I'll consider both private and public callables...
-
- Note, looks like `__all__` does in fact work fine for modules, so that's good to know for the future. I still think the decorator approach works better -- for example, what if someone added names which were not valid tasks (i.e. private names, or ...
-
- Upon further reflection, I think I prefer the class-based approach. My original hesitation was mostly in the interest of preserving backwards-compatibility. I believe the class-based approach encourages more pluggable tasks that can ultimately...
-
- That's true, I guess. Of course then (nitpick alert!) we either have task names start looking like CamelCase or we ditch PEP-8 to some degree, neither of which I really like. At any rate, original point stands -- classes are an interesting aven...
-
- We could make BaseTask's `__init__` perform the setup and call `self.run(*args, **kwargs)` too. That'd avoid a LoC as you could just just say MyTask().
-
- * CLI help text should hopefully mention "module" and/or "import" if there's room for it * Tutorial should mention this explicitly -- it doesn't * There's a quick mention in the usage docs that should be expanded a bit.
Also available in: Atom