py2exe has a new maintainer
I am taking over the maintenance and support of py2exe from Thomas Heller. As he announced a few weeks ago he is looking to focus on other things. py2exe has been very useful to me over the years and I look forward to keeping it every bit as useful in the future. I plan to make the transition as smooth as possible for users of py2exe. I don't plan to make changes to the license other than adding my name to the list of people not to sue. I will try to be as helpful as Thomas has been in supporting py2exe on the py2exe mailing list and comp.lang.python. The mailing list, the SourceForge project, and the Wiki will continue in their current locations. The web site is moving to http://www.py2exe.org and the old site will forward to the new one so any bookmarks should still work. I will be releasing version 0.6.3 very soon with a few changes Thomas and others have made over the last few weeks. After that my priorities for py2exe will be: - Support - Documentation (which should help familiarize me with the code) - Automated tests (to point out when I haven't familiarized myself enough) - Bug fixes Any help on any of these fronts will be greatly appreciated. After I feel comfortable with things, I hope to work with other projects in the Python packaging community (e.g., cx_Freeze, PyInstaller/McMillan, py2app, setuptools, etc.) to see if we can't find synergies that will make all of them better. I recognize that different packagers are better for different audiences because of licensing, platform, Python versions, and module support among other things. Working together on the common parts (identifying dependencies, customized handling of modules with unique needs, etc.) should make all of the packagers serve their niches better. I'd like to thank Thomas for the great work he's done with py2exe over the years. He's set a very high standard for me to try and maintain. Jimmy
On Oct 4, 2005, at 5:01 PM, Jimmy Retzlaff wrote:
After I feel comfortable with things, I hope to work with other projects in the Python packaging community (e.g., cx_Freeze, PyInstaller/McMillan, py2app, setuptools, etc.) to see if we can't find synergies that will make all of them better. I recognize that different packagers are better for different audiences because of licensing, platform, Python versions, and module support among other things. Working together on the common parts (identifying dependencies, customized handling of modules with unique needs, etc.) should make all of the packagers serve their niches better.
py2app has code for the common parts that are relatively abstracted out of py2app itself and should be platform agnostic, but I just don't have the time (or need) to work on py2app right now let alone make contributions to the general python packaging infrastructure... However, it's there and the license is compatible with just about anything, so feel free to make use it of it or ask questions about it. On the other hand, setuptools/eggs solves a lot of these problems (given appropriate metadata), so I'd target integration with that first and then bring in the "legacy" support that py2app does pretty well. Requiring appropriate metadata from the packages themselves has a much brighter future than maintaining an external "quirks" infrastructure in (each) application packager. -bob
At 05:16 PM 10/4/2005 -0700, Bob Ippolito wrote:
On the other hand, setuptools/eggs solves a lot of these problems (given appropriate metadata), so I'd target integration with that first and then bring in the "legacy" support that py2app does pretty well. Requiring appropriate metadata from the packages themselves has a much brighter future than maintaining an external "quirks" infrastructure in (each) application packager.
Also, setuptools supports adding setup() keywords and commands in a more extensible way than subclassing Distribution, so there's no need to maintain a bunch of code to hook into the distutils if you just plug in with setuptools. See: http://peak.telecommunity.com/DevCenter/setuptools#creating-distutils-extens... At this point, the easy_install command is capable of dumping all the needed eggs and any generated wrapper scripts into a target directory. What it doesn't have is: * frontend wrappers/packaging to actually build the .exe or app and resources * module-finding or stdlib packaging to locate and bundle the needed portion of the standard library It would be cool if these things could be integrated in such a way that a single setup() could be used to create both an OS X application and a Windows .exe. As it happens, setuptools supports specifying additional eggs needed to run a particular setup command, so we can actually delay the requirement of the egg containing py2exe or py2app until somebody actually requests the command. On the other hand, it's also possible that the metadata could be bundled into the egg metadata directory, which would then make it possible to have external bundling tools that just use the eggs to build the application, without needing to run the setup script at all.
On 10/5/05, Jimmy Retzlaff
I am taking over the maintenance and support of py2exe from Thomas Heller. As he announced a few weeks ago he is looking to focus on other things. py2exe has been very useful to me over the years and I look forward to keeping it every bit as useful in the future. [...] I'd like to thank Thomas for the great work he's done with py2exe over the years. He's set a very high standard for me to try and maintain.
And I'd like to thank *you* for taking over. I strongly feel that py2exe is an important part of Python for Windows, and it would have been a great loss if it withered away like Gordon McMillan's Installer seems to have. Kudos to Thomas for passing the torch on before that happened. Best of luck with your plans for py2exe. Paul.
participants (4)
-
Bob Ippolito -
Jimmy Retzlaff -
Paul Moore -
Phillip J. Eby