classification
Title: Windows build identification incomplete
Type: Stage:
Components: Versions: Python 3.2
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, loewis, nadeem.vawda, ned.deily
Priority: deferred blocker Keywords:

Created on 2011-05-09 23:04 by loewis, last changed 2012-06-19 23:09 by loewis. This issue is now closed.

Messages (7)
msg135664 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-05-09 23:04
The Unix build identifies itself with a string such as

Python 3.2.1b1 (3.2:5b34f84ca773, May 10 2011, 00:58:43)

and sys._mercurial then is ('CPython', '3.2', '5b34f84ca773')

In the Windows build, the identification is

Python 3.2.1b1 (default, May 10 2011, 00:33:43) [MSC v.1500 32 bit (Intel)] on win32

and sys._mercurial is ('CPython', '', '')

Not sure whether this is a release blocker, but it's definitely a step backwards from 3.2.0.
msg135695 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2011-05-10 09:52
Note, the Unix build only identifies itself like that if there is a working copy of hg on $PATH at configure time.  If not, the version string also silently defaults to "default".  That requirement creates a bit of a problem for the OS X installer build script since hg is not currently shipped with OS X and the build script goes to some lengths to ensure that the build environment is not contaminated with non-system components, including setting PATH to standard system values.  It might also be an issue for some other Unix platform builds.  My preference would be to add an AC_PATH_PROG check or some such to configure.in to be able to specify an HG environment variable rather than having to open up PATH.  Comments?
msg135759 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-05-11 06:33
Ned: I agree this is desirable (i.e. the shipped binaries ought to carry proper build identification). I also think this is independent from this issue, though, since the changes to integrate build identification into the window build process won't be unrelated to any autoconf changes we may need.
msg135861 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-05-12 20:37
Martin, you're probably the only one who can fix this in reasonable time anyway.  So I'd not let it block 3.2.1.

(If all else fails, you can give the Windows build the correct identification manually, right?)
msg135891 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-05-13 08:03
I'd rather not patch the build process manually during a release, so probably there just won't be a hg build identification in the Windows binaries, then.
msg163215 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-06-19 20:17
I guess this is not an issue anymore.
msg163231 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-06-19 23:09
It's indeed resolved.
History
Date User Action Args
2012-06-19 23:09:57loewissetstatus: pending -> closed
resolution: out of date -> duplicate
messages: + msg163231
2012-06-19 20:17:54georg.brandlsetstatus: open -> pending
resolution: out of date
messages: + msg163215
2011-05-13 08:03:55loewissetmessages: + msg135891
2011-05-12 20:37:50georg.brandlsetpriority: release blocker -> deferred blocker

messages: + msg135861
2011-05-11 06:33:37loewissetmessages: + msg135759
2011-05-10 09:52:01ned.deilysetnosy: + ned.deily
messages: + msg135695
2011-05-09 23:08:39nadeem.vawdasetnosy: + nadeem.vawda
2011-05-09 23:04:13loewiscreate