[MacPorts] #11267: REVISION: Python25 readline variant and now builds as a framework

[MacPorts]

#11267: REVISION: Python25 readline variant and now builds as a framework
----------------------------------------+-----------------------------------
  Reporter:  dinosaur at aztecfreenet.org  |       Owner:  reiffert at macports.org    
      Type:  enhancement                |      Status:  assigned                 
  Priority:  Normal                     |   Milestone:  Port Enhancements        
 Component:  ports                      |     Version:                           
Resolution:                             |    Keywords:  Python readline Framework
----------------------------------------+-----------------------------------
Comment (by mdickens at 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