|
| SummitMinutes |
BobIppolito |
| pythonmac.org wiki | FrontPage | RecentChanges | TitleIndex | WordIndex | SiteNavigation | HelpContents |
These are the minutes of a meeting of some of the MacPython developers (Jack Jansen, Bob Ippolito and Ronald Oussoren) at Mar 15 2004
We decided to keep the PyObjC and Python CVS repositories separate. Some things will move from the Python repository to the PyObjC repository, or, actually, their replacements will: the next version of the IDE, PackMan and BuildApplet will live in the PyObjC repository.
PyObjC will move the the Python license, we have a message from the main
old contributors that they are okay with this.
We would like to have a MacPython distribution in summer. This distribution will consist of the new IDE, PackMan, BuildApplet, PyObjC and bug fixes for the Panther Addon distribution. For the Jaguar distribution it will also contain Python 2.3.X for whatever X is current then, for the Panther Addon distribution it will rely on Apple-installed MacPython.
Both 10.2 and 10.3 are widely used, so we should try to cater for 10.2 too. 10.1 is too much work.
We need to make sure existing Python users migrating to the Mac feel comfortable with MacPython. They seem so at the moment, we need to keep it that way.
AppleScripters may be an interesting audience in the future, but we have to have more infrastructure finished before we actively target them.
Another interesting audience is education. For this we definitely need the new IDE.
Because our first aim is the summer MacPython distribution for 2.3.X we are concentrating on what is needed for that: IDE, packman, BuildApplet and icon. The others are optional (or not doable before 2.4).
Bob is going to go after the icon artist again to try and get glasses on the snake, which will hopefully make it acceptable to people with snake-fobia.
Ronald has a PackMan in PyObjC. Jack is going to look at it. The old PackMan will be dropped as soon as possible.
BuildApplet will be rewritten to be a front-end to bundlebuilder. Usability to the (relative) novice is going to be important. We envision that you drop a script on it, and then get a dialog with options (build standalone, use stdio console, include icns file, include plist file, include nib, etc). Defaults for these will be picked up similar to what old BuildApplet did, i.e. if you drop foo.py on BuildApplet it will look for foo.icns and if it is found fill it in, etc.
BuildApplet will not only be able to save the resulting applet, but optionally also the bundlebuilder call you would use to create it. BuildApplet should be a GUI only, if it needs functionality this will be put into bundlebuilder.
Whether BuildApplet will be a front-end to bundlebuilder or to Bobs next generation bundlebuilder remains to be seen, probably the latter. In that case it would also acquire functionality (but somewhat hidden so as not to daunt newcomers) to select which modules to include/exclude, etc.
We talked a little abou toolbox module naming, and the need to get rid of mactoolboxglue in the Python core library, but postponed most of that.
On the pythonw issue: for 2.4 we should add something like MacOS.NeedWM() (in addition to the existing WMAvailable()). This would test whether WM access is available, and if not print a decent human-readable error message and exit. We would then use this in EasyDialogs, probably Tkinter, etc etc etc. Not before 2.4, though.
We could make life for X11 lovers easier by creating a standard place to put X11-dependent modules, such as non-aqua _tkinter. /Library/Python/2.3/x11 comes to mind. The script x11python would then prepend this location to sys.path. By providing that script and an x11-version of _tkinter we could make this the standard.
We talked a lot about this, but unfortunately I (Jack) didn't take notes.
Fortunately Ronald did take notes :-)
We've discussed some of the alternatives:
The long term view is to create an IDE that can do everything, but for the summer release we'll focus on a functional replacement for the current MacPython IDE (perfect is the enemy of good enough). In the long run we'd like to see:
The inspector should offer an interface for customizing the inspection of specific classes and instances (the Xcode debugger has this, and that's very convenient)
There are various components that could be reused: PyObjC has examples containing a classbrowser and python interpreter widget. Drawbot has a python editor widget that includes syntax coloring.
The working name for the new IDE is PyDE, the code will be located in the PyDE module of the PyObjC repository. The module has been created, but is mostly empty.
In the *very* long run Jack would like to see a VB/hypercard tool that would allow you to paint a GUI, attach code to interface elements and would then create a normal Cocoa application (a NIB file and a "normal" MVC application). The application would be able to read back the generated code to allow modification. This requires a significant amount of work.
/Library/Python and ~/Library/Python)
We're going to investigate the installer problem, it could be that it is 10.2 only. Besides the referenced problem there is also the (null) problem if you build a RootDiskOnly installer. The PyObjC and Python installer builder modules are going to be merged.
bundlebuilder2 is going to be a package, so it can include PyMacApp. It's going to have a different name (appbundle and various others flew around, Bob will pick something). It's also going to have other new nifty things.
We think that we can switch to linking extensions with "-undefined dynamic_lookup" on Panther without any adverse effectrs on compatibility. This would solve the main problem between the two pythons. What remains to be seen is whether we can somehow coerce distutils to also use dynamic_lookup when building with Apple-installed Python (which wasn't built that way).
For 2.3.X we put scripts in /Library/Python/2.3/bin and includes in /Library/Python/2.3/include through some PackMan magic. PackMan will also try to pass the include directory to later builds.
For 2.4 configure and distutils need to be taught about the DEPLOYMENT_TARGET environment variable, so it will become possible to develop for 10.2 on 10.3, and so extensions built with 10.2-python on 10.3 are automatically 10.2 compatible.
(Ronald) We also discussed createing a bdist_packman command for distutils. This would create a tarfile like bdist_dumb, but using a symbolic name for the special directories (e.g. SITE_PACKAGES/Foo/foo.py instead of /.../site-packages/Foo/Foo.py). PackMan will use these tarfiles instead of the bdist_dumb files it is currently using for binary installs.
Packman will install scripts and include files into /Library/Python instead of inside the framework (scripts is definitely for the summer release, not sure about the include files). Binaries/scripts will be installed into /Library/Python/2.3/bin. This is a bit messy for Python 2.3 (/Library/Python/2.3 is also the site-packages directory), but Python 2.4 will use the correct directory structure (site-packages will be a sibling of bin, just like in ~/Librrary/Python).
PyMacApp is goint to be renamed, and there's no reason to make it optional (at least, not for Panther). The plist-file dependency is not going to be optional, because of the "explicit is better than implicit" dictum.
Bob is going to talk to Hamish on AppScripting.
We are going to bug DSP until he delivers OSA.
Not for the summer release.
later.
The various people mumbled promises to put some work into this, at some point.
The general feeling is that it is slightly too early to go for a book.
