Patchwork python: fix interpreter directive for python scripts

login
register
mail settings
Submitter Jonathan Liu
Date Aug. 11, 2012, 6:10 a.m.
Message ID <1344665427-27181-2-git-send-email-net147@gmail.com>
Download mbox | patch
Permalink /patch/176662/
State Superseded
Headers show

Comments

Jonathan Liu - Aug. 11, 2012, 6:10 a.m.
Signed-off-by: Jonathan Liu <net147@gmail.com>
---
 package/python/python.mk | 7 +++++++
 1 file changed, 7 insertions(+)
Thomas Petazzoni - Aug. 11, 2012, 9:05 p.m.
Le Sat, 11 Aug 2012 16:10:27 +1000,
Jonathan Liu <net147@gmail.com> a écrit :

> +# Fix Python interpreter directive
> +define PYTHON_FIX_INTERPRETER
> +        sed -i '1s|#!.*python.*|#!/usr/bin/env python|' $(TARGET_DIR)/usr/bin/{easy_install,easy_install-2.7,idle,smtpd.py}
> +endef
> +
> +PYTHON_POST_INSTALL_TARGET_HOOKS += PYTHON_FIX_INTERPRETER

I agree the paths in those scripts is incorrect, *but*:

 * Should these scripts have been installed in the first place? I don't
   think there are useful for the typical usage of the Python
   interpreter, so maybe we want to get rid of them.

 * Instead of fixing this patch manually in every Python script
   installed, can we investigate on how to fix the root of the problem?
   I'm the one who has reworked the patches that get Python to
   cross-compile, and I know this stuff is really painful, but I think
   it's worth at least trying to understand a bit if there could be a
   way of handling things. From what I remember the problem is that the
   host-python uses its host sysconfig parameters even when building
   things for the target, simply because the whole Python things has
   absolutely zero understanding of the fact that we could be using
   Python on one machine to build stuff that will run on a different
   machine.

Thoughts?

Thomas
Jonathan Liu - Aug. 12, 2012, 6:57 a.m.
On 12/08/2012 7:05 AM, Thomas Petazzoni wrote:
> Le Sat, 11 Aug 2012 16:10:27 +1000,
> Jonathan Liu<net147@gmail.com>  a écrit :
>
>> +# Fix Python interpreter directive
>> +define PYTHON_FIX_INTERPRETER
>> +        sed -i '1s|#!.*python.*|#!/usr/bin/env python|' $(TARGET_DIR)/usr/bin/{easy_install,easy_install-2.7,idle,smtpd.py}
>> +endef
>> +
>> +PYTHON_POST_INSTALL_TARGET_HOOKS += PYTHON_FIX_INTERPRETER
> I agree the paths in those scripts is incorrect, *but*:
>
>   * Should these scripts have been installed in the first place? I don't
>     think there are useful for the typical usage of the Python
>     interpreter, so maybe we want to get rid of them.
Perhaps we could add a config option later on to not install idle and 
smtpd.py.
>
>   * Instead of fixing this patch manually in every Python script
>     installed, can we investigate on how to fix the root of the problem?
>     I'm the one who has reworked the patches that get Python to
>     cross-compile, and I know this stuff is really painful, but I think
>     it's worth at least trying to understand a bit if there could be a
>     way of handling things. From what I remember the problem is that the
>     host-python uses its host sysconfig parameters even when building
>     things for the target, simply because the whole Python things has
>     absolutely zero understanding of the fact that we could be using
>     Python on one machine to build stuff that will run on a different
>     machine.
easy_install and easy_install-2.7 shouldn't be in there apparently. It's 
part of setuptools package.
I've submitted a V2 patch so it only fixes idle and smtpd.py in python 
package. The V2 patch is independant of this setuptools interpreter 
directive issue.

I will see if I can look into fixing the interpreter for the setuptools 
package.

Regards,
Jonathan
Jonathan Liu - Aug. 12, 2012, 12:04 p.m.
On 12/08/2012 7:05 AM, Thomas Petazzoni wrote:
> Le Sat, 11 Aug 2012 16:10:27 +1000,
> Jonathan Liu<net147@gmail.com>  a écrit :
>
>> +# Fix Python interpreter directive
>> +define PYTHON_FIX_INTERPRETER
>> +        sed -i '1s|#!.*python.*|#!/usr/bin/env python|' $(TARGET_DIR)/usr/bin/{easy_install,easy_install-2.7,idle,smtpd.py}
>> +endef
>> +
>> +PYTHON_POST_INSTALL_TARGET_HOOKS += PYTHON_FIX_INTERPRETER
> I agree the paths in those scripts is incorrect, *but*:
>
>   * Should these scripts have been installed in the first place? I don't
>     think there are useful for the typical usage of the Python
>     interpreter, so maybe we want to get rid of them.
>
>   * Instead of fixing this patch manually in every Python script
>     installed, can we investigate on how to fix the root of the problem?
>     I'm the one who has reworked the patches that get Python to
>     cross-compile, and I know this stuff is really painful, but I think
>     it's worth at least trying to understand a bit if there could be a
>     way of handling things. From what I remember the problem is that the
>     host-python uses its host sysconfig parameters even when building
>     things for the target, simply because the whole Python things has
>     absolutely zero understanding of the fact that we could be using
>     Python on one machine to build stuff that will run on a different
>     machine.
I've submitted patch for Python to use fixed path for sys.executable to 
resolve this.

Regards,
Jonathan
Avishay Orpaz - Aug. 12, 2012, 1:19 p.m.
I've just ran into this kind of problem. It can be solved per package by
adding "-e /usr/bin/python" to the setup build command.

Avishay

2012/8/12 Jonathan Liu <net147@gmail.com>

> On 12/08/2012 7:05 AM, Thomas Petazzoni wrote:
>
>> Le Sat, 11 Aug 2012 16:10:27 +1000,
>> Jonathan Liu<net147@gmail.com>  a écrit :
>>
>>  +# Fix Python interpreter directive
>>> +define PYTHON_FIX_INTERPRETER
>>> +        sed -i '1s|#!.*python.*|#!/usr/bin/**env python|'
>>> $(TARGET_DIR)/usr/bin/{easy_**install,easy_install-2.7,idle,**smtpd.py}
>>> +endef
>>> +
>>> +PYTHON_POST_INSTALL_TARGET_**HOOKS += PYTHON_FIX_INTERPRETER
>>>
>> I agree the paths in those scripts is incorrect, *but*:
>>
>>   * Should these scripts have been installed in the first place? I don't
>>     think there are useful for the typical usage of the Python
>>     interpreter, so maybe we want to get rid of them.
>>
>>   * Instead of fixing this patch manually in every Python script
>>     installed, can we investigate on how to fix the root of the problem?
>>     I'm the one who has reworked the patches that get Python to
>>     cross-compile, and I know this stuff is really painful, but I think
>>     it's worth at least trying to understand a bit if there could be a
>>     way of handling things. From what I remember the problem is that the
>>     host-python uses its host sysconfig parameters even when building
>>     things for the target, simply because the whole Python things has
>>     absolutely zero understanding of the fact that we could be using
>>     Python on one machine to build stuff that will run on a different
>>     machine.
>>
> I've submitted patch for Python to use fixed path for sys.executable to
> resolve this.
>
>
> Regards,
> Jonathan
> ______________________________**_________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/**mailman/listinfo/buildroot<http://lists.busybox.net/mailman/listinfo/buildroot>
>
Yann E. MORIN - Aug. 12, 2012, 2:50 p.m.
Jonathan, Avishay, Thomas, All,

On Sunday 12 August 2012 15:19:17 Avishay Orpaz wrote:
> I've just ran into this kind of problem. It can be solved per package by
> adding "-e /usr/bin/python" to the setup build command.

Or introduce a new package infrastrucutre, like for autotools-based and
cmake-based packages. For example, we could add a "pysetup" (or whatver)
infrastructure:

  $(eval $(pysetup-package))

Which would automatically call ./setup in the package directory, passing the
proper arguments, instead of reimplementing that in every python packages?

Regards,
Yann E. MORIN.
Thomas Petazzoni - Aug. 12, 2012, 3:27 p.m.
Le Sun, 12 Aug 2012 16:50:03 +0200,
"Yann E. MORIN" <yann.morin.1998@free.fr> a écrit :

> Or introduce a new package infrastrucutre, like for autotools-based and
> cmake-based packages. For example, we could add a "pysetup" (or whatver)
> infrastructure:
> 
>   $(eval $(pysetup-package))
> 
> Which would automatically call ./setup in the package directory, passing the
> proper arguments, instead of reimplementing that in every python packages?

Right. We start to have more and more Python-based packages, and it
seems like those using the Python setuptools could benefit from having
a common infrastructure.

Best regards,

Thomas

Patch

diff --git a/package/python/python.mk b/package/python/python.mk
index fae4e5c..783b7b8 100644
--- a/package/python/python.mk
+++ b/package/python/python.mk
@@ -165,6 +165,13 @@  endef
 
 PYTHON_POST_INSTALL_TARGET_HOOKS += PYTHON_REMOVE_USELESS_FILES
 
+# Fix Python interpreter directive
+define PYTHON_FIX_INTERPRETER
+        sed -i '1s|#!.*python.*|#!/usr/bin/env python|' $(TARGET_DIR)/usr/bin/{easy_install,easy_install-2.7,idle,smtpd.py}
+endef
+
+PYTHON_POST_INSTALL_TARGET_HOOKS += PYTHON_FIX_INTERPRETER
+
 PYTHON_AUTORECONF = YES
 
 $(eval $(autotools-package))