convore.json/groups/fabric/features-and-bugs-for-11-and-12/messages.json

[{"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1297438719.813375, "message": "On code.fabfile.org there's a glut of tickets all marked up 1.1, and not all have patches. But we can make a 1.2 target as well as an unknown targe, to be able to push different bits around. But I am going to try and filter out of all the ones that have been in there a while with fixes, from the tickets that are in there w/o docs and tests. Suggestions welcome.", "group_id": 2227, "id": 80873}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1297457171.9722519, "message": "@morganiangoose Some of my code doesn't have docs.  Once I actually know what's being implemented and what isn't, I'll be happy document the stuff that's making it in.  Not really keen on spending a bunch of energy documenting things when there's competing implementations and no real \"this is being added\" and \"this isn't\".", "group_id": 2227, "id": 83206}, {"user_id": 7423, "stars": [], "topic_id": 4285, "date_created": 1297541723.009129, "message": "Will there be a way to produce a summary at the end of run or does that already exist? For example, if you want to keep a running count of each execution and then verify that a certain number of executions actually occurred.", "group_id": 2227, "id": 87420}, {"user_id": 4156, "stars": [], "topic_id": 4285, "date_created": 1297553203.35728, "message": "@timotheus Not currently, though there are some plans for a \"dry run\" functionality which may or may not be what you're looking for: http://code.fabfile.org/issues/show/26", "group_id": 2227, "id": 87894}, {"user_id": 7423, "stars": [], "topic_id": 4285, "date_created": 1297615368.777451, "message": "hrm, the thing it can't figure out is how the summary task is envoked", "group_id": 2227, "id": 91847}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1297615247.237417, "message": "@timotheus you can do that in task if you wanted to, it's just python afterall, so you could add in hooks to count up what you want in your tasks, and then just make a summary task that uses those counts.", "group_id": 2227, "id": 91830}, {"user_id": 7423, "stars": [], "topic_id": 4285, "date_created": 1297615393.3400381, "message": "is it a decorator like \"runs_once\"?", "group_id": 2227, "id": 91852}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1297663153.985779, "message": "@timotheus It could be a decorator or you could call it as the final task when invoking `fab` (i.e., `fab deploy summary`).", "group_id": 2227, "id": 96537}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1297696428.3520319, "message": "@tswicegood Just to note on your pull request, I've already factored out @with_settings into a branch, and just this weekend did the same for @task. Both of which merged in to mainline w/o any issues at all. So that's a plus, but I think perhaps I'm behind now with your extra bits you've added in wit hthe pull request? I'm trying to make each feature/bug into one branch, but I recall that some of your work builds off of itself?", "group_id": 2227, "id": 100530}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1297697661.0782909, "message": "The idea of a generic task object is pretty exciting. I think the with it's inclusion alot of the things in fabric that are split in to api+fab or fab only could be elimiated. As having a task as an object, one could build things that act on host lists and settings for a taskand not care how the task is called.", "group_id": 2227, "id": 100709}, {"user_id": 7423, "stars": [], "topic_id": 4285, "date_created": 1297708337.7047019, "message": "@tswicegood @morganiangoose thanks - works great.", "group_id": 2227, "id": 102999}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1297710069.440196, "message": "@morganiangoose The namespace code was added after the `@task` code which builds off of the `__all__`.  That's why they never got pulled out into separate branches.  The `via` code could probably be pulled out by itself as could the `write` changes.  I've just been too lazy to do so. :-)", "group_id": 2227, "id": 103374}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1302156792.809823, "message": "@tswicegood what does the via code do?", "group_id": 2227, "id": 572289}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302392049.795033, "message": "@morganiangoose There's some contrib functionality that does just `run`.  The `via` keyword lets you change that.  i.e., `write(\"something\", \"some file\", via=sudo)`", "group_id": 2227, "id": 606361}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1302418642.219429, "message": "So really via is just a var", "group_id": 2227, "id": 608278}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1302418691.9419539, "message": "And urging the function to actually make the connection and run the command", "group_id": 2227, "id": 608281}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302668946.2559659, "message": "@morganiangoose yup - `via` just makes it easier to recompose the method if need-be.", "group_id": 2227, "id": 657641}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1302696213.6157069, "message": "I wonder if via would be a good candidate for a context manager", "group_id": 2227, "id": 663565}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302701248.677232, "message": "fwiw, I saw an interesting piece of code inside Django the other day that lets you use a function as a decorator or context manager.", "group_id": 2227, "id": 664892}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302701225.861912, "message": "@morganiangoose definitely -- I think we could use more of the context manager style code.", "group_id": 2227, "id": 664885}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302701335.0279751, "message": "Actually, now that I think about it I don't believe it was Django but unittest2 and it's assertRaises", "group_id": 2227, "id": 664911}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302701517.8279691, "message": "They've simplified it even more in `master/trunk`.  Just a simple return early vs a straight up with if there's no func.", "group_id": 2227, "id": 665013}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302701312.870903, "message": "Basically, add `func=None` to your pseudo-decorator, if that's provided, setup a context manager and walk through it the same way Python does (try, except, finally with __enter__ and __exit__ calls).  Reduces the amount of code needed to make both ways work.", "group_id": 2227, "id": 664906}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302701465.955802, "message": "Nope, it was Django and assertNumQueries: https://github.com/django/django/blob/master/django/test/testcases.py#L527", "group_id": 2227, "id": 664986}, {"user_id": 5794, "stars": [], "topic_id": 4285, "date_created": 1302711130.090508, "message": "Nice! That'd be good for @with_settings.", "group_id": 2227, "id": 666832}, {"user_id": 960, "stars": [], "topic_id": 4285, "date_created": 1302970943.0869319, "message": "@morganiangoose My thoughts exactly. :-)  You could also use it for a @depends decorator/context processor as well. :-)", "group_id": 2227, "id": 711909}]