Activity
From 07/01/2010 to 07/30/2010
Today
-
06:17 AM Feature #200: Enhancing require
- Currently require is called as a function inside of a running task, ideally the task would fail to start if the python env variables were not set. I also feel the syntax is improved by using a decorator, as it is more similar to a regular function...
07/29/2010
-
09:43 PM Bug #198: Test server does not shut down cleanly
- Latest revision in the #7 feature branch no longer exhibits the hanging problem on 10.04 (though the revisions leading up to it do). Pretty sure this means the additional `threading.Event` I added to help ensure the `finally` clause fires, is what...
-
- Decided to go for broke and make sure this isn't normal SSH behavior, or at least normal Fabric behavior, and ran a Fab connection to the real SSH daemon on localhost. Sure enough, I'm left with a `TIME_WAIT`. So much of this mucking about with th...
-
- Realized I was never calling `disconnect_all()` to force the clients to disconnect. Got very excited that maybe it was just that dumb mistake; but no, adding it in still doesn't get rid of our `TIME_WAIT` friend. Thinking I need to get a better ha...
-
- OK, looks like `TCPServer.server_close()` is never called, and that's what would close the server socket -- hopefully this is it. Looking to see how that is supposed to be called, or if I'm supposed to be calling it (the SocketServer docs/API/sour...
-
- Stale socket appears to be server related, given that the Local Address in netstat is the 2200 port and the Foreign is the random high numbered port. Confirmed that all handle() calls in my server clean themselves up, so it may be something where ...
07/24/2010
-
- e.g.: * See if the [Viewcode extension](http://sphinx.pocoo.org/ext/viewcode.html#module-sphinx.ext.viewcode) might be useful * Replace my homerolled `issues` directive with [extlinks](http://sphinx.pocoo.org/ext/extlinks.html#module-sphinx.ex...
07/23/2010
-
- Save of in-progress work re: test server
07/22/2010
-
06:31 PM Feature #10: Overhaul contrib.project.upload_project
- I have started working on that and have addressed the first 2 points. I should be able to submit a patch this weekend.
-
- I think a possibly good approach is to try and override more of the SocketServer methods plus additional Event objects, such that all threads get registered and waited upon before terminating. This should ensure that we clean up 100% correctly. (I...
-
- Looks like our `finally` block in `handle()` is never called because, surprise, the infinite while loop never terminates (I guess the threads get forcibly axed by SocketServer or something?). Unfortunately, adding back in some threading Events ...
-
- Found [this ML post](http://www.gossamer-threads.com/lists/python/python/163591) mentioning some socket flags that can be set; that would be a workaround but it still sounds like we're not closing everything we could/should be, so source diving I go.
-
- Moving the test server bug about shutdowns into #198.
-
- On Ubuntu 8.04 and OS X 10.5, the Python process exits cleanly, but the network sockets stick around in `TIME_WAIT` for a good ~30s afterwards. (This holds true even if one Ctrl-C's out of the Python process -- the Python process sticks around, an...
-
- Tweak to test re #192
-
- Well, test still needs expect-like behavior (#177) to work right, but the actual issue is identified now I think -- it's #97. As I read it, the history goes like this: * Beginning of time: Started out by always overwriting `env.password` with any...
-
- Cleanup/reorg of test server
-
- While working on the test, noticed that connection authentication doesn't have the same "3 strikes" behavior as real SSH; I assume because the `ParamikoServer.check_auth_password` method I wrote returns AUTH_FAILED after a single test. Unsure if I...
-
- Interesting, running the entire test suite makes all tests pass, but running just the network tests causes that password-memory test to fail as mentioned above. (Not actually fail, just warn, but that indicates the test needs more work.)
07/21/2010
-
10:13 PM Feature #19: Implement parallelism/thread-safety
- So just today I got what I feel is an acceptable version of my multiprocessing branch. To test it I suggest you make use of virtualenv (and virtualenvwrapper) to keep your mainline Fabric install separate. But the code is up to date with the HEAD ...
-
- Note also that something -- hopefully the same issue causing sockets to not disconnect on my system -- causes `fab test` to hang entirely at the end of the run on Ubuntu 10.04 (but not on 8.04 or Leopard).
-
- Mostly re #19 and #7, when run via multiprocessing in sub-processes that have no TTYs attached, Fabric falls down. Mostly in the new force-stdin-to-be-bytewise code, but possibly elsewhere too. [Example output](http://pastebin.com/ZTLpSwqd) ...
-
- Note that came up via IRC while Morgan was testing out a merge of his branch and the #7 branch -- because the MP solution runs a bunch of Fabric "workers" headless without actual TTYs involved, this impacts a *lot* of assumptions Fabric makes , th...
-
- Don't hardcode local username for tests
07/20/2010
-
- Used SocketServer but had to backport the Python2.6 version since the 2.5 version is braindead re: stopping the server. It *appears* to work now (though my test still fails for some reason, hopefully something simple) though at least one of the...
-
- Re #192, think I finally got a threaded test server working
07/19/2010
-
- Bumping priority, this continues to be a pain point for 0.9.x users. It should definitely be included in 1.0.0.
07/18/2010
-
- Tweeting works, set up a new `fabuild` Twitter user for it to use. Looks like it needs to be enabled per-job, as expected. (Thankfully the login settings do not need to be specified per-job, they can inherit if necessary.) Still waiting for the...
-
- More fails
-
- Also, leaning towards not using Tox, not because I don't think it can work (though trying to troubleshoot *is* always a drag), but because lacking the sort of front-page grid I'd *like* to have, I'd rather have one test per branch+interpreter comb...
-
- More fails
-
- Testing failing tests
-
- (Wow, Python takes a long time to run its test suite.) Thinking I do want triggered-by-commit builds, as long as I can make sure the build jobs queue and don't clobber each other too much. Seems the current way to do this -- the wiki docs are o...
-
- Built Python 2.5 source package on Lucid with no hijinx (tho I just realized I neglected to verify it...will do that soon). This also forced me to upgrade my backport related Fab tasks (own dogfood eating ++) so it can deal with multiple different...
-
- Playing around with Tox, which is supposed to make it easier to test on multiple Pythons, though I can't test that aspect of it yet as I still don't have Python 2.5 on the server or 2.6 locally. It does run fine against just 2.6 on the server; doe...
-
- Playing with tox
-
- Oh, and I tried out the XUnit stuff. It's OK...many of my test "names", mostly the ones driven by test generators, cause it to break pretty awful. Does provide a handy graph on the job's main page; and would, I guess, make it a bit easier to see w...
-
- Add xunit
-
- Hudson working great in base case, quite impressed. Didn't need XUnit, apparently that's optional and lets you get more granularity/prettier pictures. Will try out soon. One problem is that there's no great builtin way I've found yet to build a...
-
- Add nose to setup setup
-
- Add setup.cfg for setup.py nosetests
07/17/2010
-
- Installed Hudson on a 10.04 RSC instance, via their Debian package mirror. In addition to Hudson itself, one needs to install `python-setuptools` and `python-dev`. No-brainers but not in my base system defaults. It's looking pretty nice so far.
-
- E.g. up/down history occasionally gets messed up, requiring an extra up arrow to get going; ctrl-a seems to operate across multiple lines sometimes; etc. Do some rigorous testing to see just what isn't working and try to figure out why, in case...
-
- Fix bug in open_shell()
07/16/2010
-
- Ticket creation will be a bit tougher since our Redmine is 0.8 based and has no REST API. Options offhand include: * More Web scraping stuff, except this time forging auth tokens and doing a POST. * Enabling ticket creation via email (which *i...
-
- Using Isaac to good effect so far; have intelligent Redmine ticket autoreply working as the first feature. Keeping the code in its own repo elsewhere since it's Ruby and not really something that belongs in the Fabric repo in any case.
-
- Refactor daemon thread helper
-
- Add partial test, logging, etc re #192. Still need server to be multithreaded or something.
-
- Once again this has turned into a "test trivial, support for writing test nontrivial" sort of ticket. I've added authentication handling of a sort to the server, insofar as it can return AUTH_FAIL if not given the right info, and the ability for t...
-
- Re #192, mostly-working auth in test server
-
- Merge branch '0.9'
-
- Update changelog re #123, #194
-
- Update changelog re #123, #194
07/15/2010
-
- Fix broken test env re #193
-
- Add installation note re: 64-bit Python on Windows. Re #194
-
- Two people so far have asked in IRC about Kerberos support, which apparently is baked into the average SSH client by way of the GSSAPI protocol. User has Kerberos ticket locally somehow, which SSH then knows to forward to the remote end for authen...
-
- Upon review, there's no good spot in the docs right now for what would really just be a one-paragraph note ("you may find fullscreen apps cause things to be written out to a smaller area afterwards, if you're not on Unix") so I'll leave it be unti...
07/14/2010
-
- N.B. tested this fix on Leopard and Hardy and it worked as-is on both, but this is one thing to keep an eye on when doing the pre-merge (certainly pre-release) test push, since it sounds like it's heavily platform dependent. Also just realized ...
-
- Applied in changeset commit:8145282ec6a8b39744aab8526df8bb232788993c.
-
- Match pty size to invoking terminal dimensions. Implements #193.
-
04:49 PM Bug #194: Windows + fab = ImportError: cannot import name output
- I guess the real problem to note here is that on 64 bit Python, you're S.O.L. for a 64bit precompiled winrandom. Rather than let the user know this, pip merrily chugs along as PyCrypto says it installs just fine (whereas it really doesn't, winrand...
-
- OK, thanks for checking (and submitting the report here instead of just posting it on SO like some people do :)). If you find something with your setup that seems like a common hang-up that might deserve mention in the install docs, please let ...
-
- Digging deeper, looks like Paramiko installed, as did its PyCrypto dependency. It looks like it failed to install a PyCrypto dependency, but marked everything as OK. Looks like winrandom is missing or built for a different environment. This isn...
-
- The SO link is also probably the same issue, though his rather unhelpfully truncated traceback makes it hard to tell.
-
- (Tweaked description formatting a bit...) Going by your traceback you don't seem to have Paramiko installed, and it's possible that the `abort` call is running into additional problems due to that. Can you install Paramiko and then see if it wo...
-
- Getting the following when trying to do anything with Fabric. This same fabfile.py that I'm using works just fine on Linux and Mac. I've got Paramiko and PyCrypto installed. Python 2.6 amd64, Windows 7 64-bit, Fabric 0.9.1. Any help would be great...
-
- [Another example snippet for the same issue](http://bytes.com/topic/python/answers/607757-getting-terminal-display-size). Also, possibly best to split out the resizing stuff into its own ticket -- not only is that even more rare than the base c...
-
- N.B. you should be using `Channel.get_pty()`'s kwargs to set this initially, and also probably hook into the 'terminal size changed' signal (as mentioned in linked thread) and use that to call `Channel.resize_pty()` (which I didn't know existed bu...
-
- [This ML thread](http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-02/msg00613.html) (link is to most informative overall post, actual code is elsewhere in the thread/quotes) is relatively useful. Sadly it looks like we need more `t...
-
- When using things interactively/with a TTY/when fullscreen apps run (possibly just with all of the above at once) I notice that the default 80x24 window settings override one's "native" terminal after anything fullscreen runs. E.g. a curses sessio...
-
- This may only occur when one switches out the user to connect as in the middle of a session (by changing `env.host_string`), but a successful connection password is not carried over for use as a sudo password (it's automatically tried and then fai...
-
- Example of sudo password prompt when `env.password` is non-empty: [jforcier@192.168.0.180] out: sudo password: [Enter for previous] On master, it looks like this instead: Password for jforcier@localhost [Enter for previous]: O...
07/13/2010
-
-
- I can't seem to replicate this now, and upon reflection I'm not sure why exactly the described setup would even be something we could defend against -- if it's creating an actual newline, doesn't that imply that a `\n` did exist too? (Or was it th...
-
- OK, reverting the fix committed earlier now makes the tests fail, and otherwise the tests pass, so that works for me. (Interestingly, another test, `puts() should prefix output with env.host_string if non-empty`, also fails when the fix is reverte...
-
- Tweak 'fab test' to use rudolf
-
- Fix minor failing test
-
- Turns out I was dumb about the env thing, that was a legitimately failing test. Derp.
-
- Add rudolf to development requirements. Color in tests == good
-
- Some use cases exist where a user would rather abort than be prompted in the case where their stored password is incorrect. Currently there's no option for this; the behavior to reprompt forever is hard coded. Should be simple enough to add a n...
-
- Minor cleanup
-
- Response server tests now use responses dict. Re #183
07/12/2010
-
07:54 AM Bug #187: make run use_sudo
- let me make one more comment: in another issue you think (if i understand you right) about having some global(?) sudo setting that makes "caller chains"like these obsolete. i don's like passing arguments up and down either, but as the functional...
-
- hallo jeff, i have patterns like these: def funkylocalstuff(param, use_sudo=False): run("foo", use_sudo=use_sudo) run("bar", use_sudo=use_sudo) run("baz", use_sudo=use_sudo) yes, of course i can do a ifthenelse in...
07/11/2010
-
- We're already using `@wraps`, this is something different that it cannot solve by itself, unfortunately.
-
- I don't see a need for this, as `run` and `sudo` have identical function signatures (as of 1.0, anyways, the order of the shared arguments are identical) and so `sudo` can be literally dropped in for `run` as needed. The `use_sudo` kwargs in other...
07/10/2010
-
- use functools.wraps
-
- some time ago i needed contrib.files.contains with grep -f instead of grep. had to copypaste it though.
-
- i usually tweak this like: def _run(cmd, use_sudo=False, **kwargs): """run, maybe use_sudo""" return sudo(cmd, **kwargs) if use_sudo else run(cmd, **kwargs)
-
- run should also honour use_sudo.,
07/08/2010
-
- OK, it took some ugly module level global crap (as in, use of the `global` keyword) but I have added nose-compatible package level setup/teardown methods that start up and stop the fake SSH server. Up next: * Update tests so they reference the m...
-
- Re #183, REALLY have test server working now. Still more polishing but it seems solid.
-
- Using a threading event I can successfully terminate the loop, but then that points out the bigger issue (why does this always happen?) of: it's just like the sshd shutting down! Thus the 2nd attempt at using the test server will fail because Fabr...
-
- Re #183, state tweaks to make loop behave better
-
- Tests still don't work; they just hang when trying to terminate the loop (i.e. the contextmanager never exits, and/or the server loop never finishes). Need to reconsider how exactly I intend to use the server; right now I think it exits when th...
-
- Strange, now that I uncommented the channel closure, I'm unable to replicate the issue, just ran about 4-5 times in a row and it all worked smoothly. May have just been too confused/tired last night? Will test a bit more, then forge ahead assum...
-
- Well duh, the problem here is that the client is never finishing up -- the IO threads wait for the channel to be closed (or something similar) and since the server never closes it, the client never gets to the next execution call as it's still wai...
07/07/2010
-
- Lots of poking at various parts of the loop to no real avail. Did find that the original issue seemed to be that we were overwriting the channel object at the top of the loop no matter what, but sometimes we get the channel first and THEN the comm...
-
- (Note: it *may* not actually be related to the unexpected/bad input, since I am now seeing it occasionally with the "good" `run()` calls too. Given that the input should not be affecting things anyway, I guess this is a good thing, and will try to...
-
- Verified that it is connected to the unexpected input, as swapping around the order still causes it to bail out on the "bad" `run()` statement. Quickly scanning the server source I'm not sure why it would behave any differently save for sending...
-
- Specific examples of error messages re: the above follow. "Channel is not open" occurring in `exec_command`: Traceback (most recent call last): File "/Volumes/data/Users/jforcier/Documents/Code/fabric/fabric/main.py", line 483, in m...
-
10:44 AM Feature #3: Make use of ssh_config where possible
- 2Ustun Ozgur: here is patch that add basic support of .ssh/config file (only hostname, port and user). 2Jeff Forcier: if you want merge this into master branch, I can clear code
-
- No work has been done on the ticket at this point in any branch, so your ssh_config file shouldn't be read at all at this point in time -- it won't affect Fabric in any way. When we *do* implement this feature, it'll definitely honor the Port s...
-
04:01 AM Feature #3: Make use of ssh_config where possible
- Does the dev version honor ~/.ssh/config settings for ports other than 22? I have defined non-standard ports for my servers, but with fabric, I have to specify not only the hostname, but also the port number; even though with ssh I can just login....
07/06/2010
-
-
- This is a dupe of #44, which is fixed in master but hasn't yet been backported to 0.9.x.
-
11:12 AM Bug #186: rsync to non-standard port not working
- hmm, actually it does not fix it. I suck.
-
- currently the rsycn command line is constructed using env.host (which does not contain the port set in env.hosts) so non-22 port does not work. This fixes it: # Create and run final command string cmd = "rsync %s %s %s@%s:%s:%s" % (op...
Also available in: Atom