transition to mercurial
jason pellerin
Google code now supports mercurial, and nose will be moving to hg on
google code shortly. In the mean time, please refrain from checking in
to svn. Instead, you can fork this bitbucket repos:
http://bitbucket.org/jpellerin/nose/
And send me pull requests with any changes.
IMPORTANT NOTE! If you forked a repos of the same name in the past few
days, you need a new fork; the previous version was lacking branch
names.
Many thanks to Augie Fackler for able hg assistance.
JP
jason pellerin
nose's google code repository is now hosted under mercurial.
hg clone http://python-nose.googlecode.com/hg/ python-nose
svn repos still exists but will receive no more updates.
Since google code doesn't support the kinds of forking that bitbucket
does (yet), I still encourage everyone who wants to contribute to make
a bitbucket repos. You can fork from
http://bitbucket.org/jpellerin/nose and pull regularly from the google
code repos to stay up to date.
nose3 development will continue to live on bitbucket at
http://bitbucket.org/jpellerin/nose3, again until google code supports
forking like bb.
JP
James Casbon
> Since google code doesn't support the kinds of forking that bitbucket
> does (yet), I still encourage everyone who wants to contribute to make
> a bitbucket repos.
Without meaning to stir the DVCS hornet's nest too vigorously:
* what kinds of forking are you talking about here that google code
doesn't support?
* does hg do sane named local branches yet?
Kumar McMillan
> * does hg do sane named local branches yet?
separate clones for ephemeral branches (i.e. hg clone
http://bitbucket.org/jpellerin/nose ./nose-experimental-feature )
unless someone else has a better idea for that use case.
>
> >
>
jason pellerin
> Without meaning to stir the DVCS hornet's nest too vigorously:
> * what kinds of forking are you talking about here that google code
> doesn't support?
Bitbucket, like github, lets any user easily clone and host a copy of
a repos. Google code doesn't, so there's no easy way to get the D part
of DVCS working well only on google code.
> * does hg do sane named local branches yet?
Define "sane"? hg does named local branches but as a consumer of
changes I prefer per-user forks.
JP
James Casbon
>
> On Tue, Apr 28, 2009 at 10:27 AM, James Casbon <cas...@gmail.com> wrote:
>
>> Without meaning to stir the DVCS hornet's nest too vigorously:
>> * what kinds of forking are you talking about here that google code
>> doesn't support?
>
> Bitbucket, like github, lets any user easily clone and host a copy of
> a repos. Google code doesn't, so there's no easy way to get the D part
> of DVCS working well only on google code.
Ah, ok.
>> * does hg do sane named local branches yet?
>
> Define "sane"? hg does named local branches but as a consumer of
> changes I prefer per-user forks.
Point taken ;)
Thanks for the info. I'll stop stirring now.
John J Lee
[...]
> nose3 development will continue to live on bitbucket at
> http://bitbucket.org/jpellerin/nose3, again until google code supports
> forking like bb.
What's nose3?
John
Holger Krekel
Jason and or others, do you plan to have a single code base for
supporting 2.4 through to 3k?
cheers,
holger
>
> John
>
>
> >
>
jason pellerin
>
> On Tue, Apr 28, 2009 at 11:57 PM, John J Lee <j...@pobox.com> wrote:
>>
>> On Tue, 28 Apr 2009, jason pellerin wrote:
>> [...]
>>> nose3 development will continue to live on bitbucket at
>>> http://bitbucket.org/jpellerin/nose3, again until google code supports
>>> forking like bb.
>> [...]
>>
>> What's nose3?
>
> making nose compatible with python3.
Yup. Sorry I left out that somewhat relevant bit of information. :)
> Jason and or others, do you plan to have a single code base for
> supporting 2.4 through to 3k?
Not exactly. nose3 is a single codebase, but it is going to support
only 2.6 and above. The soon-to-be "old" nose will continue to support
2.3 through 2.6, jython and (somewhat, hopefully getting better)
IronPython.
JP
Holger Krekel
>> Jason and or others, do you plan to have a single code base for
>> supporting 2.4 through to 3k?
>
> Not exactly. nose3 is a single codebase, but it is going to support
> only 2.6 and above. The soon-to-be "old" nose will continue to support
> 2.3 through 2.6, jython and (somewhat, hopefully getting better)
> IronPython.
or is there some other reason why having a single code base for
2.3 till 3 is a problem?
holger
> JP
>
> >
>
jason pellerin
There's a ton of backwards-compatibility cruft all over nose that I
want to get rid of, from the bundled version of doctest to the many
version checks for things 2.3 doesn't support to the horrors caused by
supporting 'python setup.py test' via setuptools.... But mostly I want
to be able to use context managers and have generators and exceptions
not step all over each other because that will allow great
simplification of the context suite class and the load/run process.
Also 2.6 has __future__ imports that make keeping a single 2/3
codebase sane much easier.
JP