pmxbot IRC Log Viewer

[15:26:57] <qwebirc16912> Hey guys. Does pip supports hooks? basically I want `pip freeze > req.txt` to be run whenever I do pip install or remove some package. any suggestions?

[15:30:51] <Wooble> what, without running your test suite first?

[15:32:59] <qwebirc16912> well I want to be run after uninstall also

[15:33:08] <qwebirc16912> so, I don't really care about tests

[16:36:57] <jessamynsmith> qwebirc16912: I guess you could script it yourself

[16:40:27] <qwebirc16912> jessamynsmith: thats what I did :)

[16:43:19] <jessamynsmith> I handle this scenario differently

[16:43:46] <jessamynsmith> I have a git pre commit hook that runs all my tests, lints my code, and also verifies that requirements files are up to date with the virtualenv

[16:46:40] <doismellburning> jessamynsmith: is that not what a CI server's for? :P

[16:46:51] <jessamynsmith> I'd rather not break my builds

[16:47:01] <jessamynsmith> but yes, it is similar to what that does

[16:47:10] <doismellburning> I'm happy to break builds on non-mainline branches

[16:47:43] <jessamynsmith> different styles, I guess

[16:48:18] <jessamynsmith> doismellburning: my CI server is mostly to deploy to heroku, if all is well :p

[16:48:22] <jessamynsmith> it does verify that all is well

[16:50:32] <jessamynsmith> doismellburning: how do you work that in a team environment? only ever one person per branch, and CI builds every branch? how do you collaborate

[16:51:14] <doismellburning> jessamynsmith: we don't _enforce_ one person per branch, but that's what tends to happen

[16:51:16] <carljm> jessamynsmith: our CI builds every branch (where "our" doesn't include doismellburning - just giving another data point :-) )

[16:51:32] <jessamynsmith> carljm: is there an easy way to do that on Jenkins?

[16:51:33] <carljm> jessamynsmith: and we frequently have multiple people working on a branch

[16:51:43] <doismellburning> jessamynsmith: GHPRB and strong alcohol

[16:51:46] <jessamynsmith> (build every branch, I mean)

[16:51:46] <carljm> jessamynsmith: we use Circle CI, not Jenkins, where its automatic

[16:51:53] <carljm> no idea about Jenkinds

[16:51:58] <carljm> *Jenkins

[16:52:02] <jessamynsmith> as far as I know, you have to manually set up builds

[16:52:02] <carljm> I try to avoid it :-)

[16:52:09] <doismellburning> carljm: wise

[16:52:16] <jessamynsmith> eh, employers don't always let you change everything to whatever you want

[16:52:17] <doismellburning> we're migrating from Jenkins to Circle

[16:52:33] <carljm> jessamynsmith: they certainly don't! especially when switching to services that charge money...

[16:52:42] <doismellburning> carljm: good thing Circle's free :P

[16:52:49] <jessamynsmith> doismellburning: but only for public, no?

[16:52:53] <doismellburning> jessamynsmith: no

[16:52:53] <jessamynsmith> we weren't even using git, so

[16:52:55] <carljm> jessamynsmith: nope

[16:53:00] <jessamynsmith> oh really

[16:53:01] <jessamynsmith> interesting

[16:53:02] <carljm> doismellburning: but you only get one container

[16:53:08] <doismellburning> jessamynsmith: you just pay for more parallelism

[16:53:12] <jessamynsmith> ah

[16:53:19] <carljm> if you have Selenium tests and a full build takes 20+ minutes, a single container gets frustrating quickly.

[16:53:27] <jessamynsmith> I actually finished that job a couple months ago, so it's not my problem now

[16:53:33] <jessamynsmith> but good to know

[16:53:40] <jessamynsmith> all my personal stuff is on circle anyway

[16:53:47] <doismellburning> carljm: oh sure

[16:54:01] <carljm> jessamynsmith: in any case, we do have multiple people collaborating on a branch frequently. a long-term broken build on a branch is irritating (and we discourage it), but not a deal-breaker

[16:54:11] <doismellburning> carljm: my point is more, you don't _need_ to pay, even if there's many occasions where you'll want to

[16:54:18] <carljm> doismellburning: yep

[16:54:22] <doismellburning> we tend to not have many long-term branches

[16:54:26] <jessamynsmith> carljm: that was going to be my next question, if you discourage broken builds

[16:54:37] <carljm> we don't have long-term branches either

[16:54:37] <doismellburning> they're usually a sign of insufficient incrementality

[16:54:47] <carljm> i meant "long-term broken build" relative to the lifespan of the branch.

[16:54:50] <doismellburning> oh right, sure

[16:55:10] <carljm> the branch might last a week at most if its complex, if the tests are broken on it for a few days that's "long-term"

[16:55:14] <jessamynsmith> my second to last company we had a stuffed animal of shame, that sat on the desk of whoever broke a build last

[16:55:34] <doismellburning> jessamynsmith: see, I don't care - we break the build all the time, screw it

[16:55:40] <doismellburning> that's what the CI server + PRs are for

[16:55:42] <carljm> jessamynsmith: we don't really consider a broken build in a branch to be a "broken build" in that sense.

[16:55:46] <jessamynsmith> very different approach

[16:55:49] <carljm> we consider it a "branch that isn't ready for merge yet"

[16:55:58] <doismellburning> carljm: exactly

[16:55:59] <carljm> a broken build in master we take much more seriously

[16:56:07] <jessamynsmith> I dunno, I find it pretty annoying when I want to commit and I can't because someone else brokethe build

[16:56:17] <doismellburning> "broke-the-build" shame is for people using CVS/SVN

[16:56:19] <jessamynsmith> yeah, sure, I can stash and work on something else

[16:56:24] <jessamynsmith> but it's still annoying

[16:56:24] <doismellburning> where branching's hard so people don't

[16:57:01] <carljm> jessamynsmith: well if you don't have a commit hook that forces everything to pass before you commit, you don't have the "can't commit" problem :-)

[16:57:18] <doismellburning> heh

[16:57:33] <carljm> if the front-end people have some failing JS tests in the branch still, I can happily commit Python if I know the Python tests are passing. etc.

[16:58:01] <carljm> or even if its failing Python tests, if I know the same ones were failing before my commit

[16:58:02] <doismellburning> carljm: see at that point, I'd get them to branch off the branch ;)

[16:58:18] <carljm> like I say, we still do try to avoid it, just don't consider it a huge problem if it happens

[16:58:20] <doismellburning> (this is why we have mostly single-author branches)

[16:58:29] <jessamynsmith> carljm: I've only ever worked at places that disallow commits to broken builds

[16:58:37] <jessamynsmith> it's not a matter of a hook, it's a matter of process

[16:58:53] <jessamynsmith> so... do you even run tests locally?

[16:58:58] <jessamynsmith> or do you just commit whatever

[16:59:03] <carljm> sure, all the time

[16:59:05] <carljm> no, not at all

[16:59:13] <doismellburning> I have a tendency to commit whatever

[16:59:16] <carljm> it's just a different view of branches vs master, more than a different view of tests

[16:59:16] <jessamynsmith> just trying to see how far this, "I don't care if the build is broken" approach takes it

[16:59:19] <doismellburning> but I'll sometimes run tests locally

[16:59:23] <doismellburning> depends on the project tbh

[16:59:29] <carljm> branches are for experimentation

[16:59:34] <carljm> sometimes experimentation involves spikes

[16:59:43] <doismellburning> I virtually never bother running the selenium suite locally, or making sure I have a local PG for that testing

[16:59:47] <doismellburning> (as an example)

[16:59:49] <carljm> (in our case <100% coverage is a 'broken build', so that's the most frequent form)

[17:00:05] <doismellburning> carljm: hah now _that_ is the case where I tend to run tests locally

[17:00:19] <carljm> disallowing broken builds in branches would be a very problematic restriction on collaboration on experiments

[17:00:25] <doismellburning> agreed

[17:00:48] <doismellburning> I want people to _be able to_ run tests locally, but I don't want them to have to

[17:00:50] <carljm> like doismellburning, the only type of tests we really rely on CI for is Selenium, because they're so slow

[17:00:58] <jessamynsmith> that I can understand

[17:01:06] <jessamynsmith> we never disallowed new commits if selenium was broken

[17:01:45] <carljm> to be clear, I don't see this as a case of not taking broken builds seriously

[17:01:50] <carljm> we take them extremely seriously, in master

[17:01:53] <doismellburning> nod

[17:01:57] <carljm> tolerating that would be a killer

[17:01:59] <doismellburning> just not on $random-branch

[17:02:03] <carljm> it's really a different view of the purpose of branches

[17:02:18] <carljm> and the value of frequent commits, even of experimental/unfinished code

[17:02:37] <doismellburning> http://blog.doismellburning.co.uk/2015/05/29/some-things-id-like-you-to-do-when-writing-software/#PRs.for.everything - "try things out in a safe environment"

[17:02:41] <carljm> we consider it much more problematic if a developer "goes dark" for days on end because they're trying to get everything all shaped up before committing

[17:02:48] <doismellburning> carljm: absolutely

[17:03:12] <doismellburning> I do not want people sitting polishing something before they push it

[19:00:08] <The-Compiler> It seems virtualenv doesn't work on Windows with --python=... - is this something weird on my system or a virtualenv bug? http://paste.the-compiler.org/view/c9882277

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 23rd of June, 2015