I really don't know why I bother; these are all generated files.
But I don't recall how to regenerate them nor how to fix the generator.
The hardest part was fixing two mutual recursive imports;
somehow changing "import foo" into "from . import foo" where
foo and bar import each other AND both are imported from __init__.py
caused things to break. Bah.
number of tests, all because of the codecs/_multibytecodecs issue described
here (it's not a Py3K issue, just something Py3K discovers):
http://mail.python.org/pipermail/python-dev/2006-April/064051.html
Hye-Shik Chang promised to look for a fix, so no need to fix it here. The
tests that are expected to break are:
test_codecencodings_cn
test_codecencodings_hk
test_codecencodings_jp
test_codecencodings_kr
test_codecencodings_tw
test_codecs
test_multibytecodec
This merge fixes an actual test failure (test_weakref) in this branch,
though, so I believe merging is the right thing to do anyway.
something (overridable through Install-command entry)
- Hidden status is now determined by flavor == hidden, not by
missing Download-URL. Hidden packages behave like installer packages.
- Made some error messages a bit more understandable.
Because there's new functionality the version has been upped to 0.5.
- using a different database for non-final releases should only be done
for X.Y.0. Non-final micro releases can use the default database just fine,
as they are required to be backward compatible.
- there were no accessor functions for the global per-database fields
- packages and their dependencies were installed in order in stead
of in reverse order.
donated by Kevin Ollivier. This is now the default downloader.
- Added a watcher mechanism, whereby downloaders and unpackers (and,
later builders) can give status feedback to the user. When running
pimp as a command line tool in verbose mode print this output.
- Try not only "darwin-7.X.Y" but also "darwin-7.X" and "darwin-7",
so far we've never had to create anew database for a minor release.
- Distinguish between the various different installs (user-installed
MacPython, apple-installed MacPython, other).
by request of Donovan Preston. In return, he promised to use this
to create a Python OSA component, which would turn Python
into a first-class OSA scripting language (like AppleScript itself).
until now: the inheritance of default values was the wrong way around.
This caused app bundles to get a type of "BNDL" instead of "APPL".
Apparently this is not a problem until you try to drag your app to
the dock.
----------------------------------------------------------------------
- added bundle_id/--bundle-id option, to specify the CFBundleIndentifier
#765615:
- in the appropriate situation, prepend $PATH with our path instead of
setting it.
installed Python, yet include any modules not in the std lib
- reworked extension module inclusion code: put all .so files in
a subdirectory of Contents/Resources/, but more importantly,
correctly support extensions that are submodules.
the toplevel package. This already worked for elements, but now for
properties too. Fixes#753925.
- Even better, the toplevel class (such as Finder.Finder) now inherits
the element and property dictionaries of its application class and has
the necessary glue to allow you to say
f = Finder.Finder()
f.get(f.name)
prefixes, any file that is skipped during a per-user install that matches
this set is *not* an error; Systemwide-only is a boolean that says the
package cannot be installer per-user.
pimp_update if it exists. Upped the version number to indicate this.
Fixes#731626.
- Added -V (print version) and -u (specify database URL) options when run
as a command line tool.
- Allow setting the destination install directory. If this is set then
it is used for the modules, other items (header files, etc) are not
installed, and warnings are printed if the package would have liked to.
Unfortunaltey binary installs seem broken due to a tarfile bug (#721871)
or my misunderstanding of how tarfile works.
to lookup properties declared in base classes. Looking at it I'm not sure
what the official scope if the property codes is, maybe it is only the
(OSA) class in which they are used. But giving them global scope hasn't been
a problem so far.
Regenerated the standard suites, which are now also space-indented.
the Standard_Suite, but various other suites do expect it (the Finder
implements get() without declaring it itself). It is probably another
case of OSA magic. Adding them to the global base class.
within a certain context. Give them an _Prop_ prefix, so they don't
accidentally obscure an element from another suite (as happened with
the Finder). Comparisons I'm not sure about, so I left them as global
names.
Also got rid of the lists if declarations, they serve no useful purpose.
you to say something like "talker.count(want=Address_Book.people)" in
stead of having to manually create the aetypes.Type(Address_Book.people.want)
OSA type.
This is a first step towards regenerating the modules with newer, MacOSX,
versions of these programs, and using the programmatic interface to
get at the terminology in stead of poking in resource files.