Re: Python executables inside libraries
On Thu, Oct 21, 2004 at 10:53:32PM +1000, Matthew Palmer wrote: >On Thu, Oct 21, 2004 at 09:25:41AM +0200, Magnus Therning wrote: >> I have a silly little problem with getting Python's distutils to play >> nice with Debian packaging. The library I am packaging (PyGGy) has a few >> python files that double as executable scripts (in short they have '#! >> /usr/bin/python' at the top of the file, while still being part of a >> library, and they are executable, I am sure you know what I mean ;-). >> Distutils insists on leaving them non-executable after a './setup.py >> build'. However, since they contain that first line lintian complains >> that they are scripts, but non-executable: > >[...] > >> Do I leave it them the way they are, or is there a nice way of resolving >> this? > >Resolve the problem by making up your mind -- are they scripts (and >hence need +x and quite possibly a home in /usr/bin) or are they >library files, and hence no #! and a -x. Well, they can't go into /usr/bin, they are part of the library. However, for some reason upstream decided to put the python equivalent of a main() in some of the files that make up the library. The package I am trying to Debianise is PyGgy (bug #277567). It's a lexer/parser for Python. Upstream decided that the parser package (pyggy.pyggy) should double as an executable script (it creates parser tables for all parser description files it's given on the command line). This sort of thing isn't uncommon in Python, I believe. Removing the executable flag would leave the Debianised package different from the upstream package. I can't find anything in the Debian Python Policy mentioning this "problem". How do other maintainers do? /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] http://magnus.therning.org/ In my opinion, shareware tends to combine the worst of commercial software (no sources) with the worst of free software (no finishing touches). I simply do not believe in the shareware market at all. -- Linus Torvalds signature.asc Description: Digital signature
Re: Python executables inside libraries
On Thu, Oct 21, 2004 at 11:41:09PM +0200, Magnus Therning wrote: > On Thu, Oct 21, 2004 at 10:53:32PM +1000, Matthew Palmer wrote: > >On Thu, Oct 21, 2004 at 09:25:41AM +0200, Magnus Therning wrote: > >> I have a silly little problem with getting Python's distutils to play > >> nice with Debian packaging. The library I am packaging (PyGGy) has a few > >> python files that double as executable scripts (in short they have '#! > >> /usr/bin/python' at the top of the file, while still being part of a > >> library, and they are executable, I am sure you know what I mean ;-). > >> Distutils insists on leaving them non-executable after a './setup.py > >> build'. However, since they contain that first line lintian complains > >> that they are scripts, but non-executable: > > > >[...] > > > >> Do I leave it them the way they are, or is there a nice way of resolving > >> this? > > > >Resolve the problem by making up your mind -- are they scripts (and > >hence need +x and quite possibly a home in /usr/bin) or are they > >library files, and hence no #! and a -x. > > Well, they can't go into /usr/bin, they are part of the library. > However, for some reason upstream decided to put the python equivalent > of a main() in some of the files that make up the library. > > The package I am trying to Debianise is PyGgy (bug #277567). It's a > lexer/parser for Python. Upstream decided that the parser package > (pyggy.pyggy) should double as an executable script (it creates parser > tables for all parser description files it's given on the command line). > This sort of thing isn't uncommon in Python, I believe. Would you reasonably want to execute those scripts in and of themselves from another program? If yes, then +x. If not, s/^#!.*$//. - Matt
Re: Python executables inside libraries
On Thu, Oct 21, 2004 at 11:41:09PM +0200, Magnus Therning wrote: > Well, they can't go into /usr/bin, they are part of the library. > However, for some reason upstream decided to put the python equivalent > of a main() in some of the files that make up the library. That's a reasonable thing to do. Just make them non-executable and remove any #! line. They can still be invoked with "python foo.py" if the user wants this. -- - mdz
