#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by mcalhoun@macports.org): Are there any objections to my committing this patch? -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by raimue@macports.org): Seems like you removed some parts of the installation, here are my concerns: * Why is libpython${branch}.dylib removed? * What happens to ${destroot}${prefix}/bin? It should only contain binaries with the branch suffix. * Why did you remove --disable-tk? Doesn't that pull in a `depends_lib port:tk`? * Not sure about the --without-readline flag, but usually readline was provided as a separate port py*-readline until now. Is this going to conflict now? Sorry, I did not test the new Portfile, but at least wanted to leave some concerns about the changes. -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by mcalhoun@macports.org): Thanks for the reply.

* Why is libpython${branch}.dylib removed? The only reason is that if another port is using the python framework installation correctly then it is not needed.

* What happens to ${destroot}${prefix}/bin? It should only contain binaries with the branch suffix. With this configuration, only versioned binary files are installed into ${destroot}${prefix}/bin.[[BR]] The python installation does this automatically.[[BR]] Non versioned binaries are located in ${frameworks_dir}/Python.framework/Versions/2.6/bin, which do not conflict with anything.

* Why did you remove --disable-tk? Doesn't that pull in a `depends_lib port:tk`? --disable-tk is not recognized by the python configure script.[[BR]] Further, I can find no mention of tk.[[BR]] I believe this is an artifact from earlier python versions.

* Not sure about the --without-readline flag, but usually readline was provided as a separate port py*-readline until now. Is this going to conflict now? --without-readline is not recognized by the python configure script.[[BR]] The configure does in fact check for how to link readline, but I can find no way of turning it off.[[BR]] There does not seem to be a problem (perhaps because one of the patchfiles includes readline in the disabled_module_list).

-- Ticket URL: <http://trac.macports.org/ticket/16933#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by blb@macports.org): I see it no longer installs ${prefix}/lib and ${prefix}/include items (all are now under the framework). This is fine for python group-based ports, but what about those that want python but aren't using the group stuff? I haven't had a chance to test one to see what happens, though many of them may need testing to see if there are issues. -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by blb@macports.org): I wonder if, as mentioned in #16334, since we may have to do symlinks from the Frameworks.../bin to ${prefix}/bin, we can add that to the port group, something like {{{python26.linkbin program}}} would automatically link Frameworks.../bin/program to ${destroot}${prefix}/bin ? With the py25-numpy example in #16334, it could append 2.6 if necessary. -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:11> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by blb@macports.org): When we implement jmr's group unification stuff (#16723), we would need to push version numbers away from the Portfile itself, since it'd then be dependent upon which python version variant is being used. So my first idea would be wrong, instead, no 26 in it at all I think. -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:13> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by blb@macports.org): Replying to [comment:14 mcalhoun@…]:

May I go ahead and commit this patch, or are there unresolved concerns?

I would be happy to become a co-maintainer of python26 to help fix any bug reports concerning this patch.

Sure on both questions, I hope to try a few ports against it to make sure be we should still have some time since there still isn't a python26 port group yet. -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:15> MacPorts <http://www.macports.org/> Ports system for Mac OS

#16933: RFE: Make Python 2.6 more Framework Friendly ------------------------------------+--------------------------------------- Reporter: mcalhoun@macports.org | Owner: blb@macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: python26 | ------------------------------------+--------------------------------------- Comment(by blb@macports.org): Replying to [comment:16 raimue@…]:

Have you tried mercurial? I remember I had problems with it while I was doing the framework transition and tried to place everything inside the framework itself.

That was one of the first ones I was planning on testing, FYI. -- Ticket URL: <http://trac.macports.org/ticket/16933#comment:17> MacPorts <http://www.macports.org/> Ports system for Mac OS