On lun, may 14, 2018 at 7:14 AM, Jonathan Cave
<email address hidden> wrote:
> Thanks for the workaround suggestion. To relate this back to the
> specific problem I have been facing - the part2 from the example has
> actually been a plainbox_provider plugin part. Hence, I have tried
> locally making a change to the plugin itself and the following
> stage_packages as 'builtins' (only adding setuptools didnt seem to
> work
> for me):
>
> def __init__(self, name, options, project):
> ...
> + self.stage_packages.extend(['python3-pip', 'python3-wheel',
> 'python3-setuptools'])
>
> def build(self):
> super().build()
>
>
> This gets our previous working builds going again, which is great.
> Does it seem reasonable to carry this in the plugin to you? I think
> it is acceptable.
If you want to force the plainbox provider plugin to always use pip
from the archive, this seems reasonable. That said, this is still only
a workaround.
On lun, may 14, 2018 at 7:14 AM, Jonathan Cave packages. extend( ['python3- pip', 'python3-wheel', setuptools' ])
<email address hidden> wrote:
> Thanks for the workaround suggestion. To relate this back to the
> specific problem I have been facing - the part2 from the example has
> actually been a plainbox_provider plugin part. Hence, I have tried
> locally making a change to the plugin itself and the following
> stage_packages as 'builtins' (only adding setuptools didnt seem to
> work
> for me):
>
> def __init__(self, name, options, project):
> ...
> + self.stage_
> 'python3-
>
> def build(self):
> super().build()
>
>
> This gets our previous working builds going again, which is great.
> Does it seem reasonable to carry this in the plugin to you? I think
> it is acceptable.
If you want to force the plainbox provider plugin to always use pip
from the archive, this seems reasonable. That said, this is still only
a workaround.