PyCon WebOb Py3K sprint outcomes
Chris McDonough
========================
We provided WebOb with 100% statement coverage at the 2011 PyCon Pyramid
sprint in Atlanta GA.
Participated:
Alexandre Conrad, Patricio Paez, Whit Morriss, Rob Miller, Reed O'Brien,
Chris Shenton, Joe Dallago, Tres Seaver, Casey Duncan, Kai Groner, Chris
McDonough.
In doing so, we added roughly 700-800 unit tests, and disused existing
doctests as coverage (they are still runnable, but don't get run during
``setup.py test``).
We never did get around to actually doing any porting to Python 3.
Adding comprehensive test coverage proved to be enough work to fill
the sprint days.
The bitbucket fork on which this work was done is at
https://bitbucket.org/chrism/webob-py3k. I've made a tag in that
repository named "sprint-coverage" which represents a reasonable
place to pull from for integration into mainline.
Testing Normally
----------------
$ python2.x setup.py test
Testing Coverage
----------------
$ python2.X setup.py nosetests --with-coverage
Testing Documentation
---------------------
Doctests don't run when you run "setup.py test" anymore. To run them
manually, do:
$ cd webob
$ $MYVENV/bin/python setup.py develop
$ cd docs
$ $MYVENV/bin/python doctests.py
Blamelist
---------
- webob.acceptparse (aconrad)
- webob.byterange (ppaez)
- webob.cachecontrol (whit)
- webob.dec (rafrombrc)
- webob.descriptors (reedobrien)
- webob.etag (shentonfreude)
- webob.multidict (joe)
- webob.request (tseaver)
- webob.response (caseman/mcdonc)
- webob.exc (joe)
Doctest-to-Unit Test Conversion
-------------------------------
- tests/test_request.txt (aconrad)
- tests/test_response.txt (groner)
Sergey, can you let me know if I need to do anything except submit a
pull request to get some of this stuff merged into the mainline?
- C
chrism
Jenkins at http://jenkins.pylonsproject.org/job/webob/ .
The tests currently run and pass on Python 2.4, 2.5, 2.6, 2.7, PyPy
and Jython. This was achieved via tox. A tox.ini was added to the
package to support this.
On Mar 19, 4:49 pm, Chris McDonough <chr...@plope.com> wrote:
> Python 3 Sprint Outcomes
> ========================
>
> We provided WebOb with 100% statement coverage at the 2011 PyCon Pyramid
> sprint in Atlanta GA.
>
> Participated:
>
> Alexandre Conrad, Patricio Paez, Whit Morriss, Rob Miller, Reed O'Brien,
> Chris Shenton, Joe Dallago, Tres Seaver, Casey Duncan, Kai Groner, Chris
> McDonough.
>
> In doing so, we added roughly 700-800 unit tests, and disused existing
> doctests as coverage (they are still runnable, but don't get run during
> ``setup.py test``).
>
> We never did get around to actually doing any porting to Python 3.
> Adding comprehensive test coverage proved to be enough work to fill
> the sprint days.
>
Chris McDonough
> Python 3 Sprint Outcomes
> ========================
>
> We provided WebOb with 100% statement coverage at the 2011 PyCon Pyramid
> sprint in Atlanta GA.
> Sergey, can you let me know if I need to do anything except submit a
> pull request to get some of this stuff merged into the mainline?
Phil Jenvey noted that he gave me commit access to the WebOb repo. I'm
not sure if this was meant as a signal for me to do this merge or what,
can someone clarify?
- C
Sergey Schetinin
refactoring. If it's possible it would be great not to do a simple
merge but compact all those commits (around 400 I believe) into just a
few in the same manner previous test coverage fork was merged.
https://bitbucket.org/ianb/webob/changeset/6e60e67afbc9
https://bitbucket.org/marplatense/webobtestcoverage/issue/3/merging-upstream
> --
> You received this message because you are subscribed to the Google Groups "Paste Users" group.
> To post to this group, send email to paste...@googlegroups.com.
> To unsubscribe from this group, send email to paste-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/paste-users?hl=en.
>
>
--
Best Regards,
Sergey Schetinin
http://self.maluke.com/ -- My articles and open-source stuff
http://www.maluke.com/ -- My commercial software and custom development services
Chris McDonough
> I believe you had commit access for a while, since the AdhocAttrsMixin
> refactoring. If it's possible it would be great not to do a simple
> merge but compact all those commits (around 400 I believe) into just a
> few in the same manner previous test coverage fork was merged.
>
> https://bitbucket.org/ianb/webob/changeset/6e60e67afbc9
> https://bitbucket.org/marplatense/webobtestcoverage/issue/3/merging-upstream
While I'll do whatever you like, what's the benefit of losing history?
- C
Sergey Schetinin
> On Sun, 2011-03-20 at 22:54 +0200, Sergey Schetinin wrote:
>> I believe you had commit access for a while, since the AdhocAttrsMixin
>> refactoring. If it's possible it would be great not to do a simple
>> merge but compact all those commits (around 400 I believe) into just a
>> few in the same manner previous test coverage fork was merged.
>>
>> https://bitbucket.org/ianb/webob/changeset/6e60e67afbc9
>> https://bitbucket.org/marplatense/webobtestcoverage/issue/3/merging-upstream
>
> While I'll do whatever you like, what's the benefit of losing history?
Well, in this case the history is too verbose and in the rare case
when it will be needed we'll still have the fork where it will still
be preserved.
Chris McDonough
> On 20 March 2011 23:18, Chris McDonough <chr...@plope.com> wrote:
> > On Sun, 2011-03-20 at 22:54 +0200, Sergey Schetinin wrote:
> >> I believe you had commit access for a while, since the AdhocAttrsMixin
> >> refactoring. If it's possible it would be great not to do a simple
> >> merge but compact all those commits (around 400 I believe) into just a
> >> few in the same manner previous test coverage fork was merged.
> >>
> >> https://bitbucket.org/ianb/webob/changeset/6e60e67afbc9
> >> https://bitbucket.org/marplatense/webobtestcoverage/issue/3/merging-upstream
> >
> > While I'll do whatever you like, what's the benefit of losing history?
>
> Well, in this case the history is too verbose and in the rare case
> when it will be needed we'll still have the fork where it will still
> be preserved.
I'm going to delete the fork after it's merged, as I don't intend to
maintain it. But whatever, I'll jump through that hoop as necessary.
- C
Sergey Schetinin
> I'm going to delete the fork after it's merged, as I don't intend to
> maintain it. But whatever, I'll jump through that hoop as necessary.
Thanks, please pull the changes from trunk into the fork first though (1.0.5).
Chris McDonough
> On 21 March 2011 04:49, Chris McDonough <chr...@plope.com> wrote:
> > I'm going to delete the fork after it's merged, as I don't intend to
> > maintain it. But whatever, I'll jump through that hoop as necessary.
>
> Thanks, please pull the changes from trunk into the fork first though (1.0.5).
The fork now has the up-to-the-moment changes.
However, collapsing all the commits isn't as simple as copying files
between repositories, as there have been file deletions and moves. I am
currently running the hg "collapse" extension via "hg collapse -r
582:925". However, it's taking forever to run, and I don't think it'll
be possible to push the result up after it completes, as if I read
http://mercurial.selenic.com/wiki/CollapseExtension correctly, it seems
only intended to collapse a bunch of local commits *before* you've
pushed them up to a remote repository. In this case, the remote
repository already has those commits. In any case, I don't have any
confidence that it will work.
Can someone explain to me how to most easily do this?
- C
Ian Bicking
Sergey Schetinin
I just replace .hg of the fork with that of the main repo and then
commit the changes as usual.
Chris McDonough
> On 21 March 2011 06:14, Chris McDonough <chr...@plope.com> wrote:
> > On Mon, 2011-03-21 at 04:57 +0200, Sergey Schetinin wrote:
> >> On 21 March 2011 04:49, Chris McDonough <chr...@plope.com> wrote:
> >> > I'm going to delete the fork after it's merged, as I don't intend to
> >> > maintain it. But whatever, I'll jump through that hoop as necessary.
> >>
> >> Thanks, please pull the changes from trunk into the fork first though (1.0.5).
> >
> > The fork now has the up-to-the-moment changes.
> >
> > However, collapsing all the commits isn't as simple as copying files
> > between repositories, as there have been file deletions and moves. I am
> > currently running the hg "collapse" extension via "hg collapse -r
> > 582:925". However, it's taking forever to run, and I don't think it'll
> > be possible to push the result up after it completes, as if I read
> > http://mercurial.selenic.com/wiki/CollapseExtension correctly, it seems
> > only intended to collapse a bunch of local commits *before* you've
> > pushed them up to a remote repository. In this case, the remote
> > repository already has those commits. In any case, I don't have any
> > confidence that it will work.
> >
> > Can someone explain to me how to most easily do this?
>
> I just replace .hg of the fork with that of the main repo and then
> commit the changes as usual.
This repository has the collapsed commit:
https://bitbucket.org/chrism/webob-py3k-merge and I've sent a pull
request.
- C
Sergey Schetinin
That message is way too long, it makes it extremely hard to look at
the changes in tortoisehg and brings Chrome to crawl when viewing the
changelog page etc. I'll do the merge myself at a later time.
Chris McDonough
Oh dear. Well, you're welcome anyway.
- C
Sergey Schetinin
one compares how the changelog looks for the trunk and the fork, I
hope it's obvious that merging this way does have its benefits.
Big thanks to everyone involved <3
-Sergey
Chris McDonough
Great, thanks for doing the merge.
- C
>
> -Sergey
>