Thanks everyone for a well-tested release. 2.6.4 is out. 2.6.5 will
be a "normal" release in that fixes do not need to be restricted to
regressions.
-Barry
Are we on track to release 2.6.4 final this Sunday or do we need
another rc?
Yesterday, Tarek committed another setuptools related fix and said
that he was going to run a bunch of build tests locally. Tarek, how
did that go?
Please note that issue 7064 is still open as a release blocker. Can
we close that (again) now?
http://bugs.python.org/issue7064
I am still being very conservative about what goes in 2.6.4. Only
regressions introduced in 2.6.3 are being accepted. There's plenty of
time after that for patches to go in for 2.6.5.
-Barry
I strongly urge another release candidate. But then, I am not doing the
work, so take that advice for what it is...
On Oct 14, 2009 10:18 AM, "Barry Warsaw" <barry(a)python.org> wrote:
On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that
the idea of a release ...
No, but let's do one anyway!
So, we can either make Sunday's release rc2 and do the final release one
week later, or I can try to get an rc2 out in the next day or two, with a
final release mid-next week.
Thoughts?
-Barry
_______________________________________________
python-committers mailing list
python-committers(a)python.org
http://mail.python.org/mailman/listinfo/python-committers
At 05:16 PM 10/13/2009 +0200, Tarek Ziadé wrote:
>Yes the doctest was pretty fuzzy about what is an extension name. It's
>will be improved in 2.7.
>
>The current code is doing os.path.join()'s to join the Extension name
>with the build path,
>leading to the collateral damage you are mentioning. To fix the
>problem, the API has to be as permissive
>as it was before.
>
>I have already three or four tests to fix that problem in
>test_build_ext. If you can take a look at them and
>think of any other test that would be missing, that would be
>appreciated. Another pair of eye is never enough.
One identical to test_build_ext_path_with_os_sep, but that explicitly
uses a '/' (rather than os.sep) will identify the problem I'm
referring to, when run on Windows.
It's common practice to use /-separated paths in setup scripts,
regardless of platform. So, your current fix (converting os.sep to
'.') will work on Linux, Mac, etc., but fail on Windows when run with
the same setup.py, since os.sep is a backslash there.
(Just as a side note, if when you split off issue 7115 you'd said
what the new issue number was in 7064, or copied me to the nosy-list
on the new issue, I'd have been able to review this change and
comment on it yesterday instead of today, and I'd have done it in the
bug tracker rather than via Python-Dev.)
