On 07/05/2016 04:47 PM, Hugo Lefeuvre wrote:
> Hi Thomas,
>
>> I did lots of that in OpenStack. You can have a look at one of our tool
>> to handle the dh_auto_install for Python:
>>
>> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/build-tools/pkgos-dh_auto_install
>>
>> Th
Hi Thomas,
> I did lots of that in OpenStack. You can have a look at one of our tool
> to handle the dh_auto_install for Python:
>
> http://anonscm.debian.org/cgit/openstack/openstack-pkg-tools.git/tree/build-tools/pkgos-dh_auto_install
>
> The way to use it in your debian/rules file is to do:
>
On 06/22/2016 09:51 PM, Hugo Lefeuvre wrote:
> Hi Ben,
>
>>> The package is originally requested as a Python module[2] and it seems
>>> clear to me that the whole thing is only useful as a library
>>
>> I don't understand this statement. If it is *only* useful as a library,
>> why install the com
On 06/21/2016 11:13 PM, Hugo Lefeuvre wrote:
> Hi all !
>
> I'm currently packaging python-slugify[0], a Python application for
> slugifying unicode strings. Like here[1] upstream decided to write
> everything as a python module with an entry script placed in /usr/bin
> that calls main(). So we c
> So the question would rather be: how can I properly ask pybuild (setup.py ?)
> to install the entry point in the application package (slugify) instead of
> installing it in the library packages (python{3}-slugify) ?
So, if nobody knows, I think I'll upload the package as is.
Thanks anyway ! :
> > The entry point is generated by 'setup.py install_scripts', which is
> > executed by pybuild after files specified in *.install have been
> > installed (correct me if I'm wrong).
>
> I haven't demonstrated for this case, but I would be surprised if that's
> how it behaves. To my mind the ‘setu
On Jun 22, 2016 7:54 PM, "Barry Warsaw" wrote:
>
> On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:
>
> >This seems to be more common now that command-line invocation is
> >becoming even more discouraged. When the upstream documentation
> >recommends ‘python3 -m foo.bar’ as the primary means of inv
Hugo Lefeuvre writes:
> The entry point is generated by 'setup.py install_scripts', which is
> executed by pybuild after files specified in *.install have been
> installed (correct me if I'm wrong).
I haven't demonstrated for this case, but I would be surprised if that's
how it behaves. To my mi
On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:
>This seems to be more common now that command-line invocation is
>becoming even more discouraged. When the upstream documentation
>recommends ‘python3 -m foo.bar’ as the primary means of invoking the
>command line functionality, that really blurs th
Hi Ben,
> > The package is originally requested as a Python module[2] and it seems
> > clear to me that the whole thing is only useful as a library
>
> I don't understand this statement. If it is *only* useful as a library,
> why install the command-line entry point?
Indeed, I though about that
Hugo Lefeuvre writes:
> I'm currently packaging python-slugify[0], a Python application for
> slugifying unicode strings.
Thank you for considering the issues and asking for advice.
> Like here[1] upstream decided to write everything as a python module
> with an entry script placed in /usr/bin
11 matches
Mail list logo
