[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Markos Chandras]

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
 ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch

diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
new file mode 100644
index 0000000..ebc8830
--- /dev/null
+++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
@@ -0,0 +1,26 @@
+Prevent build system from detecting an existing installation.
+Fixes the following problem when python-setuptools is installed
+on the host:
+
+Setuptools installation detected at /usr/lib64/python2.7/site-packages
+Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
+/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
+OSError: [Errno 13] Permission denied
+
+Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
+
+Index: python-setuptools-0.6.36/setup.py
+===================================================================
+--- python-setuptools-0.6.36.orig/setup.py
++++ python-setuptools-0.6.36/setup.py
+@@ -129,10 +129,6 @@ def _being_installed():
+         return False
+     return  'install' in sys.argv[1:] or _easy_install_marker()
+ 
+-if _being_installed():
+-    from distribute_setup import _before_install
+-    _before_install()
+-
+ # return contents of reStructureText file with linked issue references
+ def _linkified(rst_path):
+     bitroot = 'http://bitbucket.org/tarek/distribute'
-- 
1.8.3.2

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Arnout Vandecappelle]

On 20/08/13 16:25, Markos Chandras wrote:
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> ---
>   ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
>   1 file changed, 26 insertions(+)
>   create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
> 
> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
> new file mode 100644
> index 0000000..ebc8830
> --- /dev/null
> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
> @@ -0,0 +1,26 @@
> +Prevent build system from detecting an existing installation.
> +Fixes the following problem when python-setuptools is installed
> +on the host:
> +
> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
> +OSError: [Errno 13] Permission denied

 This happens because setuptools is called with:

	PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"

 Yegor, Gustavo, any idea why this is called with a python path pointing
to the host? Maybe this isn't needed anymore? A quick grep in the source
doesn't indicate an obvious place where PYTHONPATH would be relevant
during install itself.

 I've just tried removing the PYTHONPATH override and it built OK, but I
haven't tested if a package installed with setuptools actually works.
Well, actually, host-setuptools _doesn't_ have that strange
PYTHONPATH override and that is of course the only one used within
buildroot itself...


 Regards,
 Arnout


> +
> +Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> +
> +Index: python-setuptools-0.6.36/setup.py
> +===================================================================
> +--- python-setuptools-0.6.36.orig/setup.py
> ++++ python-setuptools-0.6.36/setup.py
> +@@ -129,10 +129,6 @@ def _being_installed():
> +         return False
> +     return  'install' in sys.argv[1:] or _easy_install_marker()
> +
> +-if _being_installed():
> +-    from distribute_setup import _before_install
> +-    _before_install()
> +-
> + # return contents of reStructureText file with linked issue references
> + def _linkified(rst_path):
> +     bitroot = 'http://bitbucket.org/tarek/distribute'
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Yegor Yefremov]

On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 20/08/13 16:25, Markos Chandras wrote:
>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>> ---
>>   ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
>>   1 file changed, 26 insertions(+)
>>   create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>
>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>> new file mode 100644
>> index 0000000..ebc8830
>> --- /dev/null
>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>> @@ -0,0 +1,26 @@
>> +Prevent build system from detecting an existing installation.
>> +Fixes the following problem when python-setuptools is installed
>> +on the host:
>> +
>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
>> +OSError: [Errno 13] Permission denied
>
>  This happens because setuptools is called with:
>
>         PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
>
>  Yegor, Gustavo, any idea why this is called with a python path pointing
> to the host? Maybe this isn't needed anymore? A quick grep in the source
> doesn't indicate an obvious place where PYTHONPATH would be relevant
> during install itself.
>
>  I've just tried removing the PYTHONPATH override and it built OK, but I
> haven't tested if a package installed with setuptools actually works.
> Well, actually, host-setuptools _doesn't_ have that strange
> PYTHONPATH override and that is of course the only one used within
> buildroot itself...

I'll look into it. But I need some time.

Yegor

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Yegor Yefremov]

On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 20/08/13 16:25, Markos Chandras wrote:
>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>>> ---
>>>   ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
>>>   1 file changed, 26 insertions(+)
>>>   create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>
>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>> new file mode 100644
>>> index 0000000..ebc8830
>>> --- /dev/null
>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>> @@ -0,0 +1,26 @@
>>> +Prevent build system from detecting an existing installation.
>>> +Fixes the following problem when python-setuptools is installed
>>> +on the host:
>>> +
>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
>>> +OSError: [Errno 13] Permission denied
>>
>>  This happens because setuptools is called with:
>>
>>         PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
>>
>>  Yegor, Gustavo, any idea why this is called with a python path pointing
>> to the host? Maybe this isn't needed anymore? A quick grep in the source
>> doesn't indicate an obvious place where PYTHONPATH would be relevant
>> during install itself.
>>
>>  I've just tried removing the PYTHONPATH override and it built OK, but I
>> haven't tested if a package installed with setuptools actually works.
>> Well, actually, host-setuptools _doesn't_ have that strange
>> PYTHONPATH override and that is of course the only one used within
>> buildroot itself...
>
> I'll look into it. But I need some time.

The only package, that relies on setuptools is netifaces. I've applied
the patch, rebuilt BR and everything seems to be OK. I can use
netifaces, when I start the new image.

Yegor

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Markos Chandras]

On 22 August 2013 10:07, Yegor Yefremov <yegorslists@googlemail.com> wrote:
> On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
>> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> On 20/08/13 16:25, Markos Chandras wrote:
>>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>>>> ---
>>>>   ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
>>>>   1 file changed, 26 insertions(+)
>>>>   create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>
>>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>> new file mode 100644
>>>> index 0000000..ebc8830
>>>> --- /dev/null
>>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>> @@ -0,0 +1,26 @@
>>>> +Prevent build system from detecting an existing installation.
>>>> +Fixes the following problem when python-setuptools is installed
>>>> +on the host:
>>>> +
>>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
>>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
>>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
>>>> +OSError: [Errno 13] Permission denied
>>>
>>>  This happens because setuptools is called with:
>>>
>>>         PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
>>>
>>>  Yegor, Gustavo, any idea why this is called with a python path pointing
>>> to the host? Maybe this isn't needed anymore? A quick grep in the source
>>> doesn't indicate an obvious place where PYTHONPATH would be relevant
>>> during install itself.
>>>
>>>  I've just tried removing the PYTHONPATH override and it built OK, but I
>>> haven't tested if a package installed with setuptools actually works.
>>> Well, actually, host-setuptools _doesn't_ have that strange
>>> PYTHONPATH override and that is of course the only one used within
>>> buildroot itself...
>>
>> I'll look into it. But I need some time.
>
> The only package, that relies on setuptools is netifaces. I've applied
> the patch, rebuilt BR and everything seems to be OK. I can use
> netifaces, when I start the new image.
>
> Yegor
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Thanks for testing. Shall I submit a new patch removing the PYTHONPATH
variable from the makefile?

-- 
Regards,
Markos Chandras

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Arnout Vandecappelle]

On 22/08/13 11:07, Yegor Yefremov wrote:
> On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
>> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> On 20/08/13 16:25, Markos Chandras wrote:
>>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>>>> ---
>>>>    ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
>>>>    1 file changed, 26 insertions(+)
>>>>    create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>
>>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>> new file mode 100644
>>>> index 0000000..ebc8830
>>>> --- /dev/null
>>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>> @@ -0,0 +1,26 @@
>>>> +Prevent build system from detecting an existing installation.
>>>> +Fixes the following problem when python-setuptools is installed
>>>> +on the host:
>>>> +
>>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
>>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
>>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
>>>> +OSError: [Errno 13] Permission denied
>>>
>>>   This happens because setuptools is called with:
>>>
>>>          PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
>>>
>>>   Yegor, Gustavo, any idea why this is called with a python path pointing
>>> to the host? Maybe this isn't needed anymore? A quick grep in the source
>>> doesn't indicate an obvious place where PYTHONPATH would be relevant
>>> during install itself.
>>>
>>>   I've just tried removing the PYTHONPATH override and it built OK, but I
>>> haven't tested if a package installed with setuptools actually works.
>>> Well, actually, host-setuptools _doesn't_ have that strange
>>> PYTHONPATH override and that is of course the only one used within
>>> buildroot itself...
>>
>> I'll look into it. But I need some time.
>
> The only package, that relies on setuptools is netifaces. I've applied
> the patch, rebuilt BR and everything seems to be OK. I can use
> netifaces, when I start the new image.

  With "the patch", do you the original patch that removes something from 
setuptools.py, or do you mean that you removed the PYTHONPATH overrides 
from python-setuptools.mk?

  In the former case, yes it will work because that part is indeed 
redundant in our context.

  In the latter case: actually I think python-netifaces incorrectly 
selects BR2_PACKAGE_PYTHON_SETUPTOOLS, because AFAICS it doesn't use it 
at runtime.

  The way to test setuptools on the target is probably to run 
easy_install for some packages.


  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Arnout Vandecappelle]

On 22/08/13 11:17, Markos Chandras wrote:
> On 22 August 2013 10:07, Yegor Yefremov <yegorslists@googlemail.com> wrote:
>> On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov
>> <yegorslists@googlemail.com> wrote:
>>> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>>> On 20/08/13 16:25, Markos Chandras wrote:
>>>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>>>>> ---
>>>>>    ...etuptools-do-not-detect-installed-version.patch | 26 ++++++++++++++++++++++
>>>>>    1 file changed, 26 insertions(+)
>>>>>    create mode 100644 package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>>
>>>>> diff --git a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>> new file mode 100644
>>>>> index 0000000..ebc8830
>>>>> --- /dev/null
>>>>> +++ b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>> @@ -0,0 +1,26 @@
>>>>> +Prevent build system from detecting an existing installation.
>>>>> +Fixes the following problem when python-setuptools is installed
>>>>> +on the host:
>>>>> +
>>>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
>>>>> +Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
>>>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
>>>>> +OSError: [Errno 13] Permission denied
>>>>
>>>>   This happens because setuptools is called with:
>>>>
>>>>          PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
>>>>
>>>>   Yegor, Gustavo, any idea why this is called with a python path pointing
>>>> to the host? Maybe this isn't needed anymore? A quick grep in the source
>>>> doesn't indicate an obvious place where PYTHONPATH would be relevant
>>>> during install itself.
>>>>
>>>>   I've just tried removing the PYTHONPATH override and it built OK, but I
>>>> haven't tested if a package installed with setuptools actually works.
>>>> Well, actually, host-setuptools _doesn't_ have that strange
>>>> PYTHONPATH override and that is of course the only one used within
>>>> buildroot itself...
>>>
>>> I'll look into it. But I need some time.
>>
>> The only package, that relies on setuptools is netifaces. I've applied
>> the patch, rebuilt BR and everything seems to be OK. I can use
>> netifaces, when I start the new image.
>>
>> Yegor
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
> Thanks for testing. Shall I submit a new patch removing the PYTHONPATH
> variable from the makefile?

  It should probably be changed to
$(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages

  I guess it was just a typo in the original patch, forgetting to add 
$(TARGET_DIR)

  Regards,
  Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Yegor Yefremov]

On Thu, Aug 22, 2013 at 11:18 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 22/08/13 11:07, Yegor Yefremov wrote:
>>
>> On Thu, Aug 22, 2013 at 10:19 AM, Yegor Yefremov
>> <yegorslists@googlemail.com> wrote:
>>>
>>> On Wed, Aug 21, 2013 at 10:49 PM, Arnout Vandecappelle <arnout@mind.be>
>>> wrote:
>>>>
>>>> On 20/08/13 16:25, Markos Chandras wrote:
>>>>>
>>>>> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
>>>>> ---
>>>>>    ...etuptools-do-not-detect-installed-version.patch | 26
>>>>> ++++++++++++++++++++++
>>>>>    1 file changed, 26 insertions(+)
>>>>>    create mode 100644
>>>>> package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>>
>>>>> diff --git
>>>>> a/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>> b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>> new file mode 100644
>>>>> index 0000000..ebc8830
>>>>> --- /dev/null
>>>>> +++
>>>>> b/package/python-setuptools/python-setuptools-do-not-detect-installed-version.patch
>>>>> @@ -0,0 +1,26 @@
>>>>> +Prevent build system from detecting an existing installation.
>>>>> +Fixes the following problem when python-setuptools is installed
>>>>> +on the host:
>>>>> +
>>>>> +Setuptools installation detected at /usr/lib64/python2.7/site-packages
>>>>> +Renaming
>>>>> /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
>>>>>
>>>>> +/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
>>>>> +OSError: [Errno 13] Permission denied
>>>>
>>>>
>>>>   This happens because setuptools is called with:
>>>>
>>>>
>>>> PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
>>>>
>>>>   Yegor, Gustavo, any idea why this is called with a python path
>>>> pointing
>>>> to the host? Maybe this isn't needed anymore? A quick grep in the source
>>>> doesn't indicate an obvious place where PYTHONPATH would be relevant
>>>> during install itself.
>>>>
>>>>   I've just tried removing the PYTHONPATH override and it built OK, but
>>>> I
>>>> haven't tested if a package installed with setuptools actually works.
>>>> Well, actually, host-setuptools _doesn't_ have that strange
>>>> PYTHONPATH override and that is of course the only one used within
>>>> buildroot itself...
>>>
>>>
>>> I'll look into it. But I need some time.
>>
>>
>> The only package, that relies on setuptools is netifaces. I've applied
>> the patch, rebuilt BR and everything seems to be OK. I can use
>> netifaces, when I start the new image.
>
>
>  With "the patch", do you the original patch that removes something from
> setuptools.py, or do you mean that you removed the PYTHONPATH overrides from
> python-setuptools.mk?
>
>  In the former case, yes it will work because that part is indeed redundant
> in our context.
>
>  In the latter case: actually I think python-netifaces incorrectly selects
> BR2_PACKAGE_PYTHON_SETUPTOOLS, because AFAICS it doesn't use it at runtime.

But netifaces needs setuptools for build time, that's why it is there.
Perhaps one could make only HOST dependency.

>  The way to test setuptools on the target is probably to run easy_install
> for some packages.

I've tried both the patch for setup.py and removing PYTHONPATH  from
python-setuptools.mk. But I haven't tried to install real pyhon
package on my target system. Just started Python, imported netifaces
and got the list of available interfaces.

Yegor

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Gustavo Zacarias]

On 08/22/2013 07:36 AM, Yegor Yefremov wrote:

I'll answer on the last mail to make it simpler, otherwise it would be a
lot of different mails :)
Basically there's two issues going on here.

First, Markos's patch is still necessary.
On a gentoo build host which is also a desktop and where setuptools
installed is "a common thing" thing fails no matter what is done without it.

Second, what Arnout said is valid too, but it's correctness rather than
a fix. python-netifaces doesn't need python-setuptools so that can be
dropped from DEPENDENCIES and Config.in, and PYTHONPATH in
HOST_PYTHON_SETUPTOOLS_INSTALL_CMDS is in fact redundant.
However if someone wants to concoct a patch for python-setuptools
there's an additional nag for the target variant - it should
depend/select BR2_PACKAGE_PYTHON_SSL since pypi forces https these days
otherwise it'll be a terrible experience.

Regards.

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Arnout Vandecappelle]

On 22/08/13 13:12, Gustavo Zacarias wrote:
> On 08/22/2013 07:36 AM, Yegor Yefremov wrote:
>
> I'll answer on the last mail to make it simpler, otherwise it would be a
> lot of different mails :)
> Basically there's two issues going on here.
>
> First, Markos's patch is still necessary.
> On a gentoo build host which is also a desktop and where setuptools
> installed is "a common thing" thing fails no matter what is done without it.

  Markos's patch, or a yet-to-be-created patch that adds $(TARGET_DIR) to 
the PYTHONPATH instead of passing the system's pythonpath?


> Second, what Arnout said is valid too, but it's correctness rather than
> a fix. python-netifaces doesn't need python-setuptools so that can be
> dropped from DEPENDENCIES and Config.in, and PYTHONPATH in
> HOST_PYTHON_SETUPTOOLS_INSTALL_CMDS is in fact redundant.

  Actually I didn't realize the PYTHONPATH setting for the host variant 
was redundant :-)  I was only talking about the target.


> However if someone wants to concoct a patch for python-setuptools
> there's an additional nag for the target variant - it should
> depend/select BR2_PACKAGE_PYTHON_SSL since pypi forces https these days
> otherwise it'll be a terrible experience.

  But I guess that is a separate patch.

  Anyway I'm not sure if the target variant is that relevant, because it 
will not be able to install anything that requires compilation...

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Gustavo Zacarias]

On 08/22/2013 08:17 AM, Arnout Vandecappelle wrote:

>  Markos's patch, or a yet-to-be-created patch that adds $(TARGET_DIR) to
> the PYTHONPATH instead of passing the system's pythonpath?

That's possible too, testing required :)

>  Actually I didn't realize the PYTHONPATH setting for the host variant
> was redundant :-)  I was only talking about the target.

PYTHONPATH for the target is required because it's sometimes hardcoded
in installed packages unfortunately - i don't recall the exact
combination that triggered it at the moment, or it may have been some
additional python package that i used for testing and never sent
(useless, not interesting) when fixing the shebang and other details.

>  But I guess that is a separate patch.
> 
>  Anyway I'm not sure if the target variant is that relevant, because it
> will not be able to install anything that requires compilation...

Yes, something for someone to up their buildroot cred :)
I'm unsure if we want to encourage the target setuptools, there are
packages that'll install fine, and as you say the compiler ones will
fail miserably.
I'd keep it to avoid unnecessary noise and complaints with a big fat
warning that it's not the buildroot way and it's just for convenience
(and to forget about the target toolchain!).
Regards.

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Markos Chandras]

On 22 August 2013 12:24, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> On 08/22/2013 08:17 AM, Arnout Vandecappelle wrote:
>
>>  Markos's patch, or a yet-to-be-created patch that adds $(TARGET_DIR) to
>> the PYTHONPATH instead of passing the system's pythonpath?
>
> That's possible too, testing required :)
>
>>  Actually I didn't realize the PYTHONPATH setting for the host variant
>> was redundant :-)  I was only talking about the target.
>
> PYTHONPATH for the target is required because it's sometimes hardcoded
> in installed packages unfortunately - i don't recall the exact
> combination that triggered it at the moment, or it may have been some
> additional python package that i used for testing and never sent
> (useless, not interesting) when fixing the shebang and other details.
>
>>  But I guess that is a separate patch.
>>
>>  Anyway I'm not sure if the target variant is that relevant, because it
>> will not be able to install anything that requires compilation...
>
> Yes, something for someone to up their buildroot cred :)
> I'm unsure if we want to encourage the target setuptools, there are
> packages that'll install fine, and as you say the compiler ones will
> fail miserably.
> I'd keep it to avoid unnecessary noise and complaints with a big fat
> warning that it's not the buildroot way and it's just for convenience
> (and to forget about the target toolchain!).
> Regards.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Hi,

The following patch works for me

--- a/package/python-setuptools/python-setuptools.mk
+++ b/package/python-setuptools/python-setuptools.mk
@@ -20,19 +20,18 @@ endef

 define PYTHON_SETUPTOOLS_BUILD_CMDS
        (cd $(@D); \
-       PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" \
+       PYTHONPATH="$(TARGET_DIR))/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
\
        $(HOST_DIR)/usr/bin/python setup.py build)
 endef

 define HOST_PYTHON_SETUPTOOLS_INSTALL_CMDS
        (cd $(@D); \
-       PYTHONPATH="$(HOST_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
\
        $(HOST_DIR)/usr/bin/python setup.py install --prefix=$(HOST_DIR)/usr)
 endef

 define PYTHON_SETUPTOOLS_INSTALL_TARGET_CMDS
        (cd $(@D); \
-       PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" \
+       PYTHONPATH="$(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
\
        $(HOST_DIR)/usr/bin/python setup.py install
--executable=/usr/bin/python \
        --single-version-externally-managed --root=/ --prefix=$(TARGET_DIR)/usr)


Host variant is installed in
output/host/usr/lib/python2.7/site-packages/distribute-0.6.36-py2.7.egg
and target variant in output/target/usr/lib/python2.7/site-packages/setuptools

What do you think? I think the 'target variant' of setuptools can be
removed in a subsequent patch if necessary.

-- 
Regards,
Markos Chandras

[Buildroot] [PATCH] python-setuptools: Add patch to prevent detecting the host installation

[Arnout Vandecappelle]

On 22/08/13 22:33, Markos Chandras wrote:
> The following patch works for me
>
> --- a/package/python-setuptools/python-setuptools.mk
> +++ b/package/python-setuptools/python-setuptools.mk
> @@ -20,19 +20,18 @@ endef
>
>   define PYTHON_SETUPTOOLS_BUILD_CMDS
>          (cd $(@D); \
> -       PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" \
> +       PYTHONPATH="$(TARGET_DIR))/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
> \
>          $(HOST_DIR)/usr/bin/python setup.py build)
>   endef
>
>   define HOST_PYTHON_SETUPTOOLS_INSTALL_CMDS
>          (cd $(@D); \
> -       PYTHONPATH="$(HOST_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
> \
>          $(HOST_DIR)/usr/bin/python setup.py install --prefix=$(HOST_DIR)/usr)
>   endef
>
>   define PYTHON_SETUPTOOLS_INSTALL_TARGET_CMDS
>          (cd $(@D); \
> -       PYTHONPATH="/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages" \
> +       PYTHONPATH="$(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/site-packages"
> \
>          $(HOST_DIR)/usr/bin/python setup.py install
> --executable=/usr/bin/python \
>          --single-version-externally-managed --root=/ --prefix=$(TARGET_DIR)/usr)
>
>
> Host variant is installed in
> output/host/usr/lib/python2.7/site-packages/distribute-0.6.36-py2.7.egg
> and target variant in output/target/usr/lib/python2.7/site-packages/setuptools
>
> What do you think?

  Yes, please submit as a proper patch. I'll test and ack it.

> I think the 'target variant' of setuptools can be
> removed in a subsequent patch if necessary.

  It's not really necessary though. Doesn't hurt to keep it around.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F