From holger at merlinux.eu Fri Aug 1 10:15:48 2014 From: holger at merlinux.eu (holger krekel) Date: Fri, 1 Aug 2014 08:15:48 +0000 Subject: [pytest-dev] pytest github organization is taken In-Reply-To: References:

Message-ID: <20140801081548.GW7481@merlinux.eu> On Thu, Jul 31, 2014 at 22:09 +0200, Anatoly Bubenkov wrote: > i've contacted github about this problem > they say the account is NOT inactive, so all they can do is to pass a > message from us to the owner > so i've sent a polite message through them asking the owner to rename/grant > access to us > no reply yet, we'll see > > for now i've created pytest and pylib teams on bitbucket and pylib > organization on github > if github pytest organization will not be ours, then we can at least use > pylib both on bb and github Wouldn't want to go for "pylib" as an org name, it's too generic. If "pytest" is not handed over, what about "pytestorg"? Any other suggestions? best, holger > ps: still have to do PR about the organizing plugins > > > On 28 July 2014 14:22, Anatoly Bubenkov wrote: > > > Hi all > > if it was you who created this org https://github.com/pytest > > please make Holger an admin > > if this name was taken by someone who's not related to pytest in any way, > > then we should make a claim to github to get the rights i guess > > the org is empty and created Oct 21, 2013 > > > > -- > > Anatoly Bubenkov > > > > > > -- > Anatoly Bubenkov > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From bubenkoff at gmail.com Fri Aug 1 10:17:26 2014 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Fri, 1 Aug 2014 10:17:26 +0200 Subject: [pytest-dev] pytest github organization is taken In-Reply-To: <20140801081548.GW7481@merlinux.eu> References:

<20140801081548.GW7481@merlinux.eu> Message-ID: btw please everyone check all your old email addresses, which you don't use may be it was you who created pytest on github? On 1 August 2014 10:15, holger krekel wrote: > On Thu, Jul 31, 2014 at 22:09 +0200, Anatoly Bubenkov wrote: > > i've contacted github about this problem > > they say the account is NOT inactive, so all they can do is to pass a > > message from us to the owner > > so i've sent a polite message through them asking the owner to > rename/grant > > access to us > > no reply yet, we'll see > > > > for now i've created pytest and pylib teams on bitbucket and pylib > > organization on github > > if github pytest organization will not be ours, then we can at least use > > pylib both on bb and github > > Wouldn't want to go for "pylib" as an org name, it's too generic. > If "pytest" is not handed over, what about "pytestorg"? Any other > suggestions? > best, > holger > > > ps: still have to do PR about the organizing plugins > > > > > > On 28 July 2014 14:22, Anatoly Bubenkov wrote: > > > > > Hi all > > > if it was you who created this org https://github.com/pytest > > > please make Holger an admin > > > if this name was taken by someone who's not related to pytest in any > way, > > > then we should make a claim to github to get the rights i guess > > > the org is empty and created Oct 21, 2013 > > > > > > -- > > > Anatoly Bubenkov > > > > > > > > > > > -- > > Anatoly Bubenkov > > > _______________________________________________ > > Pytest-dev mailing list > > Pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > > -- Anatoly Bubenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Fri Aug 1 23:09:10 2014 From: flub at devork.be (Floris Bruynooghe) Date: Fri, 1 Aug 2014 22:09:10 +0100 Subject: [pytest-dev] extended asserts In-Reply-To: References: Message-ID: Hi, On 29 July 2014 09:24, Anatoly Bubenkov wrote: > what do you think about extending the existing assert representation with > this > https://pypi.python.org/pypi/datadiff > would be nice if we could extend datadiff with what pytest does for string > diff So datadiff is not as good as comparing strings then what py.test does now? > and then just use datadiff for all assertions > because for now, it's not too useful to see a comparison of 2 dicts in the > pytest > it's not readable > especially if 2 dicts are big We should always strive to make the assertions better. If you think they can be improved using datadiff then let's improve it. The current reprs where simply derived from unittest2 with some improvements from feedback later. > the reason why im asking without the PR is the politics about the > dependencies > as i know you're not so positive about adding them I guess new external dependencies are not ideal. But looking at datadiff it seems to be only about 300 lines of Apache licensed code. That's not a lot of code by any means. So I think there are a few options which I think are realistic: * Vendor datadiff, I think the licenses are compatible. * Re-write what datadiff produces directly inside _pytest/assertion/utils.py. It's not that a crazy task. This is only a bad idea if datadiff keeps evolving a lot, but given it's last commit was in 2012 I think we're fine. * Have datadiff as an optional dependency, if it's importable we use it for comparing stuff, otherwise use py.test's built in code. I guess I'd be -0 on this one. There's also the option of an external plugin which was already mentioned, but I think we should aim for the best exceptions out of the box (which is why i'm -0 on the last option). So I'm all for improving out of the box assertion reprs. The simplest option is vendoring datadiff (maybe with a few tweaks), any objections to that approach? The only downside I see is that the license becomes more complicated. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From bubenkoff at gmail.com Sat Aug 2 11:08:35 2014 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Sat, 2 Aug 2014 11:08:35 +0200 Subject: [pytest-dev] extended asserts In-Reply-To: References: Message-ID: On 1 August 2014 23:09, Floris Bruynooghe wrote: > So datadiff is not as good as comparing strings then what py.test does now? > > it doesn't even support such comparison - raises notimplemented > We should always strive to make the assertions better. If you think > they can be improved using datadiff then let's improve it. The > current reprs where simply derived from unittest2 with some > improvements from feedback later. > > +1 > > the reason why im asking without the PR is the politics about the > > dependencies > > as i know you're not so positive about adding them > > I guess new external dependencies are not ideal. But looking at > datadiff it seems to be only about 300 lines of Apache licensed code. > That's not a lot of code by any means. So I think there are a few > options which I think are realistic: > > * Vendor datadiff, I think the licenses are compatible. > by vendoring you mean using it as a dependency? if so, then i also prefer this way the author seems doing something at sourgeforge, so he's alive, and we can ask for PR if they will be needed about having datadiff diffs as external plugin, not putting it in the core - that was more like sandboxing approach, i think and i think it's good intention -- Anatoly Bubenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Sat Aug 2 13:19:47 2014 From: flub at devork.be (Floris Bruynooghe) Date: Sat, 2 Aug 2014 12:19:47 +0100 Subject: [pytest-dev] extended asserts In-Reply-To: References:

Message-ID: On 2 August 2014 10:08, Anatoly Bubenkov wrote: > On 1 August 2014 23:09, Floris Bruynooghe wrote: >> * Vendor datadiff, I think the licenses are compatible. > > by vendoring you mean using it as a dependency? No, vendoring means taking the datadiff source and including it in the py.test source. So we copy-paste the code and don't have an external dependency. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From bubenkoff at gmail.com Sat Aug 2 13:59:57 2014 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Sat, 2 Aug 2014 13:59:57 +0200 Subject: [pytest-dev] extended asserts In-Reply-To: References:

Message-ID: well, this will also work for me especially knowing that we'll have to extend datadiff anyway to include string comparison On 2 August 2014 13:19, Floris Bruynooghe wrote: > On 2 August 2014 10:08, Anatoly Bubenkov wrote: > > On 1 August 2014 23:09, Floris Bruynooghe wrote: > >> * Vendor datadiff, I think the licenses are compatible. > > > > by vendoring you mean using it as a dependency? > > No, vendoring means taking the datadiff source and including it in the > py.test source. So we copy-paste the code and don't have an external > dependency. > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > -- Anatoly Bubenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Aug 4 09:35:24 2014 From: holger at merlinux.eu (holger krekel) Date: Mon, 4 Aug 2014 07:35:24 +0000 Subject: [pytest-dev] extended asserts In-Reply-To: References: Message-ID: <20140804073524.GB1894@merlinux.eu> Hi Floris, On Fri, Aug 01, 2014 at 22:09 +0100, Floris Bruynooghe wrote: > Hi, > > On 29 July 2014 09:24, Anatoly Bubenkov wrote: > > what do you think about extending the existing assert representation with > > this > > https://pypi.python.org/pypi/datadiff > > would be nice if we could extend datadiff with what pytest does for string > > diff > > So datadiff is not as good as comparing strings then what py.test does now? > > > and then just use datadiff for all assertions > > because for now, it's not too useful to see a comparison of 2 dicts in the > > pytest > > it's not readable > > especially if 2 dicts are big > > We should always strive to make the assertions better. If you think > they can be improved using datadiff then let's improve it. The > current reprs where simply derived from unittest2 with some > improvements from feedback later. > > > the reason why im asking without the PR is the politics about the > > dependencies > > as i know you're not so positive about adding them > > I guess new external dependencies are not ideal. But looking at > datadiff it seems to be only about 300 lines of Apache licensed code. > That's not a lot of code by any means. So I think there are a few > options which I think are realistic: > > * Vendor datadiff, I think the licenses are compatible. > > * Re-write what datadiff produces directly inside > _pytest/assertion/utils.py. It's not that a crazy task. This is only > a bad idea if datadiff keeps evolving a lot, but given it's last > commit was in 2012 I think we're fine. That's the best option IMO. > * Have datadiff as an optional dependency, if it's importable we use > it for comparing stuff, otherwise use py.test's built in code. I > guess I'd be -0 on this one. > > There's also the option of an external plugin which was already > mentioned, but I think we should aim for the best exceptions out of > the box (which is why i'm -0 on the last option). > > > So I'm all for improving out of the box assertion reprs. The simplest > option is vendoring datadiff (maybe with a few tweaks), any objections > to that approach? The only downside I see is that the license becomes > more complicated. Isn't it maybe enough to look at the improved output and implement it? I'd ideally like to avoid licensing complications because i somewhat often get questions from companies and distributors wrt to licensing. But i agree it's not a super-big deal in this case likely. best, holger > > Regards, > Floris > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From flub at devork.be Mon Aug 4 15:03:31 2014 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 4 Aug 2014 14:03:31 +0100 Subject: [pytest-dev] extended asserts In-Reply-To: <20140804073524.GB1894@merlinux.eu> References: <20140804073524.GB1894@merlinux.eu> Message-ID: On 4 August 2014 08:35, holger krekel wrote: > On Fri, Aug 01, 2014 at 22:09 +0100, Floris Bruynooghe wrote: >> * Re-write what datadiff produces directly inside >> _pytest/assertion/utils.py. It's not that a crazy task. This is only >> a bad idea if datadiff keeps evolving a lot, but given it's last >> commit was in 2012 I think we're fine. > > That's the best option IMO. Ok, I'm happy with that too (in fact with my conservative hat on this is my preferred option), it will just take a bit longer I suspect. >> So I'm all for improving out of the box assertion reprs. The simplest >> option is vendoring datadiff (maybe with a few tweaks), any objections >> to that approach? The only downside I see is that the license becomes >> more complicated. > > Isn't it maybe enough to look at the improved output and implement it? > > I'd ideally like to avoid licensing complications because i somewhat > often get questions from companies and distributors wrt to licensing. > But i agree it's not a super-big deal in this case likely. Yes, keeping the license simple is a valid concern. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From holger at merlinux.eu Thu Aug 7 22:56:50 2014 From: holger at merlinux.eu (holger krekel) Date: Thu, 7 Aug 2014 20:56:50 +0000 Subject: [pytest-dev] pytest-2.6.1: fixes and expecting exceptions in xfail Message-ID: <20140807205650.GM1894@merlinux.eu> pytest-2.6.1: fixes and new xfail marker feature =========================================================================== pytest is a mature Python testing tool with an extensive self-test test suite, passing on many different interpreters and platforms. The 2.6.1 release is drop-in compatible to 2.5.2 and actually fixes some regressions introduced with 2.6.0. It also brings a little feature to the xfail marker which now recognizes expected exceptions, see the CHANGELOG below. See docs at: http://pytest.org As usual, you can upgrade from pypi via:: pip install -U pytest Thanks to all who contributed, among them: Floris Bruynooghe Bruno Oliveira Nicolas Delaby have fun, holger krekel Changes 2.6.1 ================= - No longer show line numbers in the --verbose output, the output is now purely the nodeid. The line number is still shown in failure reports. Thanks Floris Bruynooghe. - fix issue437 where assertion rewriting could cause pytest-xdist slaves to collect different tests. Thanks Bruno Oliveira. - fix issue555: add "errors" attribute to capture-streams to satisfy some distutils and possibly other code accessing sys.stdout.errors. - fix issue547 capsys/capfd also work when output capturing ("-s") is disabled. - address issue170: allow pytest.mark.xfail(...) to specify expected exceptions via an optional "raises=EXC" argument where EXC can be a single exception or a tuple of exception classes. Thanks David Mohr for the complete PR. - fix integration of pytest with unittest.mock.patch decorator when it uses the "new" argument. Thanks Nicolas Delaby for test and PR. - fix issue with detecting conftest files if the arguments contain "::" node id specifications (copy pasted from "-v" output) - fix issue544 by only removing "@NUM" at the end of "::" separated parts and if the part has an ".py" extension - don't use py.std import helper, rather import things directly. Thanks Bruno Oliveira. From flub at devork.be Mon Aug 11 00:12:51 2014 From: flub at devork.be (Floris Bruynooghe) Date: Sun, 10 Aug 2014 23:12:51 +0100 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches Message-ID: Hi, I was wondering if people would be fine with encouraging contributors to use bookmarks rather then named branches in mercurial for pull requests. Named branches are rather permanent and more suited for things like the 2.6.x release branch or permanent things like that. Bookmarks work really nice, the only downside is that bitbucket does not support them as well. They are shown on the commits view just fine, however when doing a pull request you will have to use the hex revision number in the bitbucket UI rather then having to use the bookmark name as it will just show the branch name "default" together with the hex number (multiple times if you have multiple heads). An additional benefit is that they wouldn't need the "closing branch" commit we get so often right now. Bookmarks do not make it to the repo on accepting a pull request. Even if a bookmark gets pushed to the hpk42/pytest repo they can be easily deleted without a commit (hg bookmark -d $name; hg push -B $name). The CONTRIBUTING.rst file would not even change that much for simple use, I've included the diff below to demonstrate. What do people think of this? Or am I the only one who doesn't like the accumulation of closed branches? Regards, Floris diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -97,11 +97,11 @@ 2. Create and activate a fork-specific v .. _checkout: 3. Clone your fork locally using `Mercurial `_ - (``hg``) and create a branch:: + (``hg``) and create a bookmark:: $ hg clone ssh://hg at bitbucket.org/YOUR_BITBUCKET_USERNAME/pytest $ cd pytest - $ hg branch your-branch-name + $ hg bookmark your-bookmark-name If you need some help with Mercurial, follow this quick start guide: http://mercurial.selenic.com/wiki/QuickStart @@ -136,7 +136,7 @@ 4. You can now edit your local working c 5. Commit and push once your tests pass and you are happy with your change(s):: $ hg commit -m"" - $ hg push -b . + $ hg push -B your-bookmark-name 6. Finally, submit a pull request through the BitBucket website: @@ -144,10 +144,14 @@ 6. Finally, submit a pull request throug :width: 700px :align: center - :: + Unfortunately bitbucket does currently not support pull requests + from bookmarks very well, this means you have to do the pull request + by the hex commit number rather then by name. To find the hex + commit revision run ``hg bookmarks`` locally and then use it in the + pull request dialog:: source: YOUR_BITBUCKET_USERNAME/pytest - branch: your-branch-name + branch: hex-commit-rev target: hpk42/pytest branch: default -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From bubenkoff at gmail.com Wed Aug 13 18:11:14 2014 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Wed, 13 Aug 2014 18:11:14 +0200 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: References: Message-ID: That's true that hg branches are not meant to be used for feature branches, and that's clearly stated in hg docs, and it's one of the reasons I like git more. However, it's important to keep the contributing workflow simple and user friendly. With the need of getting the commit hash on every PR change it makes the process very annoying IMHO. On Aug 11, 2014 12:19 AM, "Floris Bruynooghe" wrote: > Hi, > > I was wondering if people would be fine with encouraging contributors > to use bookmarks rather then named branches in mercurial for pull > requests. Named branches are rather permanent and more suited for > things like the 2.6.x release branch or permanent things like that. > > Bookmarks work really nice, the only downside is that bitbucket does > not support them as well. They are shown on the commits view just > fine, however when doing a pull request you will have to use the hex > revision number in the bitbucket UI rather then having to use the > bookmark name as it will just show the branch name "default" together > with the hex number (multiple times if you have multiple heads). > > An additional benefit is that they wouldn't need the "closing branch" > commit we get so often right now. Bookmarks do not make it to the > repo on accepting a pull request. Even if a bookmark gets pushed to > the hpk42/pytest repo they can be easily deleted without a commit (hg > bookmark -d $name; hg push -B $name). > > The CONTRIBUTING.rst file would not even change that much for simple > use, I've included the diff below to demonstrate. > > What do people think of this? Or am I the only one who doesn't like > the accumulation of closed branches? > > Regards, > Floris > > > > diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst > --- a/CONTRIBUTING.rst > +++ b/CONTRIBUTING.rst > @@ -97,11 +97,11 @@ 2. Create and activate a fork-specific v > .. _checkout: > > 3. Clone your fork locally using `Mercurial < > http://mercurial.selenic.com/>`_ > - (``hg``) and create a branch:: > + (``hg``) and create a bookmark:: > > $ hg clone ssh://hg at bitbucket.org/YOUR_BITBUCKET_USERNAME/pytest > $ cd pytest > - $ hg branch your-branch-name > + $ hg bookmark your-bookmark-name > > If you need some help with Mercurial, follow this quick start > guide: http://mercurial.selenic.com/wiki/QuickStart > @@ -136,7 +136,7 @@ 4. You can now edit your local working c > 5. Commit and push once your tests pass and you are happy with your > change(s):: > > $ hg commit -m"" > - $ hg push -b . > + $ hg push -B your-bookmark-name > > 6. Finally, submit a pull request through the BitBucket website: > > @@ -144,10 +144,14 @@ 6. Finally, submit a pull request throug > :width: 700px > :align: center > > - :: > + Unfortunately bitbucket does currently not support pull requests > + from bookmarks very well, this means you have to do the pull request > + by the hex commit number rather then by name. To find the hex > + commit revision run ``hg bookmarks`` locally and then use it in the > + pull request dialog:: > > source: YOUR_BITBUCKET_USERNAME/pytest > - branch: your-branch-name > + branch: hex-commit-rev > > target: hpk42/pytest > branch: default > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at florian-schulze.net Wed Aug 13 18:44:46 2014 From: mail at florian-schulze.net (Florian Schulze) Date: Wed, 13 Aug 2014 18:44:46 +0200 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: References:

Message-ID: <8A9B51CF-5BAE-452B-AD26-98DAF4F380AB@florian-schulze.net> Hi! Same here. Also using the hash, will the PR update if you make further commits, like it does with a branch? Regards, Florian Schulze On 13 Aug 2014, at 18:11, Anatoly Bubenkov wrote: > That's true that hg branches are not meant to be used for feature > branches, > and that's clearly stated in hg docs, and it's one of the reasons I > like > git more. > However, it's important to keep the contributing workflow simple and > user > friendly. With the need of getting the commit hash on every PR change > it > makes the process very annoying IMHO. > On Aug 11, 2014 12:19 AM, "Floris Bruynooghe" wrote: > >> Hi, >> >> I was wondering if people would be fine with encouraging contributors >> to use bookmarks rather then named branches in mercurial for pull >> requests. Named branches are rather permanent and more suited for >> things like the 2.6.x release branch or permanent things like that. >> >> Bookmarks work really nice, the only downside is that bitbucket does >> not support them as well. They are shown on the commits view just >> fine, however when doing a pull request you will have to use the hex >> revision number in the bitbucket UI rather then having to use the >> bookmark name as it will just show the branch name "default" together >> with the hex number (multiple times if you have multiple heads). >> >> An additional benefit is that they wouldn't need the "closing branch" >> commit we get so often right now. Bookmarks do not make it to the >> repo on accepting a pull request. Even if a bookmark gets pushed to >> the hpk42/pytest repo they can be easily deleted without a commit (hg >> bookmark -d $name; hg push -B $name). >> >> The CONTRIBUTING.rst file would not even change that much for simple >> use, I've included the diff below to demonstrate. >> >> What do people think of this? Or am I the only one who doesn't like >> the accumulation of closed branches? >> >> Regards, >> Floris >> >> >> >> diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst >> --- a/CONTRIBUTING.rst >> +++ b/CONTRIBUTING.rst >> @@ -97,11 +97,11 @@ 2. Create and activate a fork-specific v >> .. _checkout: >> >> 3. Clone your fork locally using `Mercurial < >> http://mercurial.selenic.com/>`_ >> - (``hg``) and create a branch:: >> + (``hg``) and create a bookmark:: >> >> $ hg clone ssh://hg at bitbucket.org/YOUR_BITBUCKET_USERNAME/pytest >> $ cd pytest >> - $ hg branch your-branch-name >> + $ hg bookmark your-bookmark-name >> >> If you need some help with Mercurial, follow this quick start >> guide: http://mercurial.selenic.com/wiki/QuickStart >> @@ -136,7 +136,7 @@ 4. You can now edit your local working c >> 5. Commit and push once your tests pass and you are happy with your >> change(s):: >> >> $ hg commit -m"" >> - $ hg push -b . >> + $ hg push -B your-bookmark-name >> >> 6. Finally, submit a pull request through the BitBucket website: >> >> @@ -144,10 +144,14 @@ 6. Finally, submit a pull request throug >> :width: 700px >> :align: center >> >> - :: >> + Unfortunately bitbucket does currently not support pull requests >> + from bookmarks very well, this means you have to do the pull >> request >> + by the hex commit number rather then by name. To find the hex >> + commit revision run ``hg bookmarks`` locally and then use it in >> the >> + pull request dialog:: >> >> source: YOUR_BITBUCKET_USERNAME/pytest >> - branch: your-branch-name >> + branch: hex-commit-rev >> >> target: hpk42/pytest >> branch: default >> >> >> -- >> Debian GNU/Linux -- The Power of Freedom >> www.debian.org | www.gnu.org | www.kernel.org >> _______________________________________________ >> Pytest-dev mailing list >> Pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From msabramo at gmail.com Mon Aug 11 00:49:44 2014 From: msabramo at gmail.com (Marc Abramowitz) Date: Sun, 10 Aug 2014 15:49:44 -0700 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: References: Message-ID: <0670E937-C5DC-4F92-B458-BAEB44ED88EF@gmail.com> Cool. I tried to use hg bookmarks once or twice, wanting to use them because of their "light" nature that you mentioned and because they seemed like a closer match to the branches that I'm accustomed to in git. I stumbled on the Bitbucket part and couldn't figure out how to make it work. But now with your description (thanks!), I can probably make it work. So I'm definitely up for trying it. -Marc http://marc-abramowitz.com Sent from my iPhone 4S > On Aug 10, 2014, at 3:12 PM, Floris Bruynooghe wrote: > > Hi, > > I was wondering if people would be fine with encouraging contributors > to use bookmarks rather then named branches in mercurial for pull > requests. Named branches are rather permanent and more suited for > things like the 2.6.x release branch or permanent things like that. > > Bookmarks work really nice, the only downside is that bitbucket does > not support them as well. They are shown on the commits view just > fine, however when doing a pull request you will have to use the hex > revision number in the bitbucket UI rather then having to use the > bookmark name as it will just show the branch name "default" together > with the hex number (multiple times if you have multiple heads). > > An additional benefit is that they wouldn't need the "closing branch" > commit we get so often right now. Bookmarks do not make it to the > repo on accepting a pull request. Even if a bookmark gets pushed to > the hpk42/pytest repo they can be easily deleted without a commit (hg > bookmark -d $name; hg push -B $name). > > The CONTRIBUTING.rst file would not even change that much for simple > use, I've included the diff below to demonstrate. > > What do people think of this? Or am I the only one who doesn't like > the accumulation of closed branches? > > Regards, > Floris > > > > diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst > --- a/CONTRIBUTING.rst > +++ b/CONTRIBUTING.rst > @@ -97,11 +97,11 @@ 2. Create and activate a fork-specific v > .. _checkout: > > 3. Clone your fork locally using `Mercurial `_ > - (``hg``) and create a branch:: > + (``hg``) and create a bookmark:: > > $ hg clone ssh://hg at bitbucket.org/YOUR_BITBUCKET_USERNAME/pytest > $ cd pytest > - $ hg branch your-branch-name > + $ hg bookmark your-bookmark-name > > If you need some help with Mercurial, follow this quick start > guide: http://mercurial.selenic.com/wiki/QuickStart > @@ -136,7 +136,7 @@ 4. You can now edit your local working c > 5. Commit and push once your tests pass and you are happy with your change(s):: > > $ hg commit -m"" > - $ hg push -b . > + $ hg push -B your-bookmark-name > > 6. Finally, submit a pull request through the BitBucket website: > > @@ -144,10 +144,14 @@ 6. Finally, submit a pull request throug > :width: 700px > :align: center > > - :: > + Unfortunately bitbucket does currently not support pull requests > + from bookmarks very well, this means you have to do the pull request > + by the hex commit number rather then by name. To find the hex > + commit revision run ``hg bookmarks`` locally and then use it in the > + pull request dialog:: > > source: YOUR_BITBUCKET_USERNAME/pytest > - branch: your-branch-name > + branch: hex-commit-rev > > target: hpk42/pytest > branch: default > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From nicoddemus at gmail.com Thu Aug 14 17:25:17 2014 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 14 Aug 2014 12:25:17 -0300 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: <0670E937-C5DC-4F92-B458-BAEB44ED88EF@gmail.com> References: <0670E937-C5DC-4F92-B458-BAEB44ED88EF@gmail.com> Message-ID: I stumbled on the same thing. It's unfortunate that Bitbucket's support for bookmarks in PRs is lacking. :( Does any one know if the PR updates automatically when further commits are made, as Florian, asked? I have no problem myself in using bookmarks, but the "Contributing" section should mention this along with a "how-to" to workaround Bitbucket's limitations on that regard. On Sun, Aug 10, 2014 at 7:49 PM, Marc Abramowitz wrote: > Cool. I tried to use hg bookmarks once or twice, wanting to use them > because of their "light" nature that you mentioned and because they seemed > like a closer match to the branches that I'm accustomed to in git. > > I stumbled on the Bitbucket part and couldn't figure out how to make it > work. But now with your description (thanks!), I can probably make it work. > So I'm definitely up for trying it. > > -Marc > http://marc-abramowitz.com > Sent from my iPhone 4S > > > > On Aug 10, 2014, at 3:12 PM, Floris Bruynooghe wrote: > > > > Hi, > > > > I was wondering if people would be fine with encouraging contributors > > to use bookmarks rather then named branches in mercurial for pull > > requests. Named branches are rather permanent and more suited for > > things like the 2.6.x release branch or permanent things like that. > > > > Bookmarks work really nice, the only downside is that bitbucket does > > not support them as well. They are shown on the commits view just > > fine, however when doing a pull request you will have to use the hex > > revision number in the bitbucket UI rather then having to use the > > bookmark name as it will just show the branch name "default" together > > with the hex number (multiple times if you have multiple heads). > > > > An additional benefit is that they wouldn't need the "closing branch" > > commit we get so often right now. Bookmarks do not make it to the > > repo on accepting a pull request. Even if a bookmark gets pushed to > > the hpk42/pytest repo they can be easily deleted without a commit (hg > > bookmark -d $name; hg push -B $name). > > > > The CONTRIBUTING.rst file would not even change that much for simple > > use, I've included the diff below to demonstrate. > > > > What do people think of this? Or am I the only one who doesn't like > > the accumulation of closed branches? > > > > Regards, > > Floris > > > > > > > > diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst > > --- a/CONTRIBUTING.rst > > +++ b/CONTRIBUTING.rst > > @@ -97,11 +97,11 @@ 2. Create and activate a fork-specific v > > .. _checkout: > > > > 3. Clone your fork locally using `Mercurial < > http://mercurial.selenic.com/>`_ > > - (``hg``) and create a branch:: > > + (``hg``) and create a bookmark:: > > > > $ hg clone ssh://hg at bitbucket.org/YOUR_BITBUCKET_USERNAME/pytest > > $ cd pytest > > - $ hg branch your-branch-name > > + $ hg bookmark your-bookmark-name > > > > If you need some help with Mercurial, follow this quick start > > guide: http://mercurial.selenic.com/wiki/QuickStart > > @@ -136,7 +136,7 @@ 4. You can now edit your local working c > > 5. Commit and push once your tests pass and you are happy with your > change(s):: > > > > $ hg commit -m"" > > - $ hg push -b . > > + $ hg push -B your-bookmark-name > > > > 6. Finally, submit a pull request through the BitBucket website: > > > > @@ -144,10 +144,14 @@ 6. Finally, submit a pull request throug > > :width: 700px > > :align: center > > > > - :: > > + Unfortunately bitbucket does currently not support pull requests > > + from bookmarks very well, this means you have to do the pull request > > + by the hex commit number rather then by name. To find the hex > > + commit revision run ``hg bookmarks`` locally and then use it in the > > + pull request dialog:: > > > > source: YOUR_BITBUCKET_USERNAME/pytest > > - branch: your-branch-name > > + branch: hex-commit-rev > > > > target: hpk42/pytest > > branch: default > > > > > > -- > > Debian GNU/Linux -- The Power of Freedom > > www.debian.org | www.gnu.org | www.kernel.org > > _______________________________________________ > > Pytest-dev mailing list > > Pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Thu Aug 14 23:52:20 2014 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 14 Aug 2014 22:52:20 +0100 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: References: <0670E937-C5DC-4F92-B458-BAEB44ED88EF@gmail.com> Message-ID: On 14 August 2014 16:25, Bruno Oliveira wrote: > I stumbled on the same thing. It's unfortunate that Bitbucket's support for > bookmarks in PRs is lacking. :( Yes, that is unfortunate. But note that for a simple contribution, as explained by the CONTRIBUTING.rst guide, this does not even occur since you won't be creating more then one head. So one can simply create the PR from default. > Does any one know if the PR updates automatically when further commits are > made, as Florian, asked? Yes, the PRs do update automatically if you update the head/bookmark. > I have no problem myself in using bookmarks, but the "Contributing" section > should mention this along with a "how-to" to workaround Bitbucket's > limitations on that regard. That's what the diff I sent in my original mail did, or was that insufficient. I don't really want to write much more as it'll start covering edge cases and just confuse matters more. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From flub at devork.be Thu Aug 14 23:57:14 2014 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 14 Aug 2014 22:57:14 +0100 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: References:

Message-ID: On 13 August 2014 17:11, Anatoly Bubenkov wrote: > However, it's important to keep the contributing workflow simple and user > friendly. With the need of getting the commit hash on every PR change it > makes the process very annoying IMHO. True, it would be nicer if bitbucket did this properly. Also worth noting maybe that when you create a PR on bitbucket from a branch with multiple heads it will default to the tip, which given that you've probably just pushed this is more often then not the correct one. Seems like on average the response is fairly negative, unless my explanations suddenly blew away your reservations but I doubt that. So let's leave it until bitbucket finally supports PRs from bookmarks properly (if ever, at EuroPython they couldn't say it was for the scheduled future though recognised it was a bit rubbish). -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From nicoddemus at gmail.com Fri Aug 15 04:49:33 2014 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 14 Aug 2014 23:49:33 -0300 Subject: [pytest-dev] Encouraging the use of bookmarks rather then branches In-Reply-To: References: <0670E937-C5DC-4F92-B458-BAEB44ED88EF@gmail.com> Message-ID: On Thu, Aug 14, 2014 at 6:52 PM, Floris Bruynooghe wrote: > Yes, that is unfortunate. But note that for a simple contribution, as > explained by the CONTRIBUTING.rst guide, this does not even occur > since you won't be creating more then one head. So one can simply > create the PR from default. I agree that for the simple case this would be sufficiently simple. > Yes, the PRs do update automatically if you update the head/bookmark. > Oh ok, thanks for the clarification. > > I have no problem myself in using bookmarks, but the "Contributing" > section > > should mention this along with a "how-to" to workaround Bitbucket's > > limitations on that regard. > > That's what the diff I sent in my original mail did, or was that > insufficient. I don't really want to write much more as it'll start > covering edge cases and just confuse matters more. > I'm sorry, somehow I missed that completely from the original message. Reading it now, it seems more than enough as a general guideline. :) Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From bubenkoff at gmail.com Fri Aug 22 15:03:57 2014 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Fri, 22 Aug 2014 15:03:57 +0200 Subject: [pytest-dev] latest pytest and pytest-xdist Message-ID: Hi anybody knows about the source of such message after test run: Unhandled exception in thread started by > ? -- Anatoly Bubenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: