Among other issues, the Apple-supplied 0.9.7 libs for the 10.5 ABI cannot
verify newer SHA-256 certs as now used by python.org services. Document
in the installer ReadMe some of the certificate management issues that
users now need to be more concerned with due to PEP 476's enabling cert
verification by default. For now, continue to use the Apple-supplied
0.9.8 libs for the 10.6+ installer since they use Apple private APIs to
verify certificates using the system- and user-managed CA keychain stores.
Values in the range of an unsigned long long, but outside of the range
of a signed long long were serialized as a negative value.
Due to a bug in PyObjC my test scripts indicated that the previous behavior
matched Apple's plist code, instead the handle large unsigned values correctly.
The change to plistlib.py is from a patch by Serhiy.
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface. Fixed
shebang lines in the unittestgui and checkpip scripts.
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface. Fixed
shebang line to use python3 executable in the unittestgui script.
* Negative integer support in binary plists was broken
* Better exception for invalid data
* Fix the versionadded/versionchanged markup in the documentation
* Add the interface cleanup to what's new for 3.4
upgrade pip by default, using the bundled pip provided by the new ensurepip
module. A new configure option, --with-ensurepip[=upgrade|install|no], is
available to override the default ensurepip "--upgrade" option. The option
can also be set with "make [alt]install ENSUREPIP=[upgrade|install\no]".
in bin directories for all configurations: non-framework vs framework,
and single arch vs universal builds. pythonx.y-32 is now always
installed for 64-bit/32-bit universal builds. The obsolete and
undocumented pythonw* symlinks are no longer installed anywhere.
This patch adds support for binary plists on OSX to plistlib (based
on a patch by 'dpounces').
The patch also cleans up the API for the plistlib module.
Some third-party projects, such as matplotlib and PIL/Pillow,
depended on being able to build with Tcl and Tk frameworks in
/Library/Frameworks. They were unable to build with the built-in
Tcl/Tk and/or execute correctly.
Make it easier for users to make use of the backup _tkinter linked
with the third-party Tcl and Tk frameworks in /Library/Frameworks.
The two tkinter variants are now installed in separate directories
under a new lib-tkinter. This allows per-user selection by
manipulating sys.path, directly or with PYTHONPATH. If this
proves useful, we can supply a more convenient user interface
to supply the paths. For now, this remains somewhat experimental.
Make it easier for users to make use of the backup _tkinter linked
with the third-party Tcl and Tk frameworks in /Library/Frameworks.
The two tkinter variants are now installed in separate directories
under a new lib-tkinter. This allows per-user selection by
manipulating sys.path, directly or with PYTHONPATH. If this
proves useful, we can supply a more convenient user interface
to supply the paths. For now, this remains somewhat experimental.
of OPT for special build options. By setting OPT, some compiler-specific
options like -fwrapv were overridden and thus not used, which could result
in broken interpreters when building with clang.
64-bit/32-bit installer for 10.6+. It is no longer necessary
to install a third-party version of Tcl/Tk 8.5 to work around the
problems in the Apple-supplied Tcl/Tk 8.5 shipped in OS X 10.6
and later releases.
of OPT for special build options. By setting OPT, some compiler-specific
options like -fwrapv were overridden and thus not used, which could result
in broken interpreters when building with clang.
1. ppc arch detection for extension module builds broke with Xcode 5
2. ppc arch detection in configure did not work on OS X 10.4
3. -sysroot and -arch flags were unnecessarily duplicated
4. there was no obvious way to configure an intel-32 only build.
64-bit/32-bit installer for 10.6+. It is no longer necessary
to install a third-party version of Tcl/Tk 8.5 to work around the
problems in the Apple-supplied Tcl/Tk 8.5 shipped in OS X 10.6
and later releases.
- Remove OS X installer and Mac/Makefile dependencies on /Developer which
no longer exists with Xcode 4; the referenced tools have been installed
into the usr/bin tool root since Xcode 3.
- Support adding the SDK usr/bin tool root to the installer's PATH via the
SDK_TOOLS_BIN environment variable.
different parsing of the Makefile by distutils.sysconfig and
sysconfig in the case when an intermediate config vars, used to
construct PY_CFLAGS or PY_LDFLAGS, has a trailing space character.
In this case, the OS X installer build script was leaving a
trailing space in the OPT and LDFLAGS config vars. The space is not
significant and it's not worth toying with the Makefile parsing.
build paths from configuration variables cached in _sysconfigdata.py, as
is already done for the installed Makefile. This avoids a distuils test
case failure in test_ldshared_value.
properly skip uncompilable files and to compile existing
files in site-packages if reinstalling. Also, no longer
attempt to install a documentation link in /Developer
as that no longer necessarily exists with Xcode 4.3+.
installer package from the OS X Makefile for Python 3. It has
never worked on Python 3 and is not needed there as pre-10.3.9
installs are no longer supported.
and link with a private copy of OpenSSL, like installers targeted
for 10.5 already do, since Apple has deprecated use of the system
OpenSSL and removed its header files from the Xcode 7 SDK. Note
that this configuration is not currently used to build any
python.org-supplied installers and that the private copy of
OpenSSL requires its own root certificates.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r88475 | ned.deily | 2011-02-21 12:44:27 -0800 (Mon, 21 Feb 2011) | 3 lines
Issue #11268: Prevent Mac OS X Installer failure if Documentation
package had previously been installed.
........
the system-provided Python. Also, properly guard a new Python 3 only
installer build step so that build-installer.py can stay compatible
with the 2.7 version. (with release manager approval for 3.2rc2)
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r88007 | ned.deily | 2011-01-14 21:44:21 -0800 (Fri, 14 Jan 2011) | 5 lines
Remove spurious copy of Mac/IDLE/idlemain.py left over from
conversion from Python 2 build process. The correct version
is in Mac/IDLE/IDLE.app/Contents/Resources/
........
svn+ssh://svn.python.org/python/branches/py3k
........
r87791 | georg.brandl | 2011-01-06 11:05:26 +0100 (Do, 06 Jan 2011) | 1 line
#10844: update copyright years in Mac plists.
........
Both the Makefile and the script that is used on OSX to create the binary
installer refer to the directory containing the Makefile using the name
'config'. This name was changed with the new ABI (with default build flags
it is now named config-3.2m). This patch ensures that both files use the
correct name.
The build-installer.py script contains one other change: it now tests for the
Tcl/Tk framework version by looking at the 'Current' symlink in the framework
instead of runnning a script. This makes it possible to verify the version
that is in the SDK that's used during the build instead of the version that
is installed on the system.
Builds are not yet fully supported on Python 3 as some parts
of the build process (like the documentation build chain)
are still dependent on Python 2.
Without this patch the i386/x86_64 installer for OSX 10.6
lies in the ReadMe file and the "Important Information" screen
of the installer (that is, the installer claims it supports
the i386 and ppc architectures insetead of the ones it really
supports)
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r85059 | ronald.oussoren | 2010-09-28 15:57:58 +0200 (Tue, 28 Sep 2010) | 5 lines
Add support for the ZSH shell to the "Update Shell Profile" script
on MacOSX.
Patch by Sylvain Mora, issue #9701.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81649 | ronald.oussoren | 2010-06-02 05:47:14 +0200 (Wed, 02 Jun 2010) | 5 lines
Fix for issue8868: without this patch 'MacOS.WMAvailable()' will return
False on MacOSX 10.5 or earlier and scripts won't be able to access GUI
functionality.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80647 | ronald.oussoren | 2010-04-30 13:20:14 +0200 (Fri, 30 Apr 2010) | 11 lines
Fix for issue #3646: with this patch it is possible to do a
framework install of Python in your home directory (on OSX):
$ configure --enable-framework=${HOME}/Library/Frameworks
$ make && make install
Without this patch the framework would get installed just fine,
but 'make install' would try to install the application bundles
and command-line tools outside the user's home, which doesn't work
for non-admin users (and is bad form anyway).
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80232 | ronald.oussoren | 2010-04-20 07:50:44 +0200 (Tue, 20 Apr 2010) | 3 lines
Explicitly set system default for $PATH to
ensure we have a clean build environment (OSX installer)
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r80185 | ronald.oussoren | 2010-04-18 17:24:17 +0200 (Sun, 18 Apr 2010) | 12 lines
Merged revisions 80179 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80179 | ronald.oussoren | 2010-04-18 16:01:05 +0200 (Sun, 18 Apr 2010) | 5 lines
Add check to build-installer.py to ensure that
the right version of Tcl/Tk is available (on OSX)
Fixes issue #5651
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
........
r80179 | ronald.oussoren | 2010-04-18 16:01:05 +0200 (Sun, 18 Apr 2010) | 5 lines
Add check to build-installer.py to ensure that
the right version of Tcl/Tk is available (on OSX)
Fixes issue #5651
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79902 | ronald.oussoren | 2010-04-08 03:13:31 -0500 (Thu, 08 Apr 2010) | 9 lines
This check-in fixes two problems:
1) A non-critical off-by-one error in pythonw
2) A problem in the configure script that caused
builds with '--enable-framework --enable-universalsdk=/'
to fail on OSX 10.6.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r79119 | benjamin.peterson | 2010-03-19 16:42:45 -0500 (Fri, 19 Mar 2010) | 1 line
update mac installer script from the trunk #8068
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r78063 | ronald.oussoren | 2010-02-07 12:46:38 +0100 (Sun, 07 Feb 2010) | 4 lines
Mention a configure warning that almost certainly indicates that
configure is picking up a library that doesn't contain all architectures
required for a universal build on OSX.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77031 | ronald.oussoren | 2009-12-24 14:30:58 +0100 (Thu, 24 Dec 2009) | 15 lines
Issue #6834: replace the implementation for the 'python' and 'pythonw' executables on OSX.
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.
The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.
I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
........
* Remove junk documentation resources from the Python.app inside the framework
(This is a left-over from the ancient Python IDE, which was removed before 2.5)
* Ensure that the documentation is installed in a location where IDLE will see it