#11267: REVISION: Python25 readline variant and now builds as a framework ----------------------------------------+----------------------------------- Reporter: dinosaur@aztecfreenet.org | Owner: reiffert@macports.org Type: enhancement | Status: assigned Priority: Normal | Milestone: Port Enhancements Component: ports | Version: Resolution: | Keywords: Python readline Framework ----------------------------------------+----------------------------------- Comment (by mdickens@nd.edu): I applaud your efforts towards finally creating the framework Python install. Here are my Initial Note and Comments from a quick review and testing. * I'm concerned with sym-linking $prefix/lib/python2.5 and $prefix/include/python2.5 into the framework -- doing so is very non- standard. For the former, both paths ($prefix/Frameworks/.../lib/python2.5 and $prefix/lib/python2.5) can easily be made part of the default PYTHONPATH (before user additions via the environment variable) - this was done by my changes to setup.py - and Python is quite good about loading scripts and libraries from anywhere in its path - so there really is no reason -for- doing this. Reasons for avoiding it include: * The "upgrade" command will not work properly for already-installed py25-xxx ports that occupy $prefix/lib/python2.5 . Any of these currently installed ports must be first deactivated, then the new python upgraded, then those ports either activated or uninstalled/re-installed. At least in my testing, trying to activate those ports (individually, doing in a group didn't work) results in "Error: port activate failed: Not a directory", even though the port was successfully activated. While this might be a bug on 'port', it is off-putting to the end user. * It adds complexity to the install and could be confusing to end- users. * If it ain't broke, don't fix it: it's simple to allow for both of these paths to be part of the default PYTHONPATH, so why not leave things alone? * in "post-patch", there are two "Mac/IDLE/Makefile.in" ... only one is needed. * the manpages are not installed correctly, and do not work. I think the correct Portfile line is: {{{ system "cd ${destroot}${prefix}/share/man/man1 && \ ln -sf ${prefix}/Library/Frameworks/Python.framework/Versions/2.5/share/man/man1/python.1.gz python2.5.2.1.gz" }}} * variant +universal does not work for me on Mac OS X 10.5.2, when doing "make libpython2.5.dylib". It looks like someone added $(LDFLAGS) to the dylib Makefile rule. When doing universal, the "-arch" command will be added to LDFLAGS, which isn't compatible with Apple's libtool libtool can handle this without any further flags. Please remove $(LDFLAGS) to fix this problem. You can check the resulting .dylib file for universality by executing "otool -vf XXX.dylib". * Even removing the LDFLAGS, there is still an install error for me, during destroot. I don't have time to debug this further right now. * "destroot.target" * should not contain compiling or linking commands, such as "libpython2.5.dylib". This should be part of "build.target". Putting it here saves a line of Portfile code, but that 1 line really doesn't matter. * In the top-level Makefile, the target "frameworkinstall" is an alias for the target "install", which in turn does the "maninstall". Thus setting the "destroot.target" to "install" should be sufficient. * python_select: * Since "python_select" isn't part of Python, the port-activate note should probably read something like "To fully complete your installation and make python 2.5 the default, please run 'sudo python_select python25' using the separate port 'python_select'." . * Running "python_select --" results in errors. * after removing python25, the symlinks created by python_select are still around. This is not a good idea. * While I like the intent of python_select, does MacPorts really want to be distributing this level of new, untested, code that leaves issues to be resolved? * I think moving this "feature" into the Python25 (or other) Portfile would be the wisest way ... that way the end results are owned by a Port, and can be manipulated by said Port. -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/11267#comment:27> MacPorts </projects/macports> Ports system for Mac OS