Re: [Distutils] [issue1054967] bdist_deb - Debian packager
I am moving the venue for this discussion on stdeb to the distutils-sig (from http://bugs.python.org/issue1054967 ). I think this is better discussed there. On 4/29/10 10:16 PM, Éric Araujo wrote:
Éric Araujo<merwok@netwok.org> added the comment:
Andrew, I am uncomfortable with stdeb. (Trying to express respectful constructive critique, not just picking on your project.) The version in Debian testing, 0.5.1-1, still requires setuptools (actually only pkg_resources, which is split into another package in Debian, for space or politic reasons). I see, thanks for pointing this out. I thought pkg_resources was in the stdlib (or on that track). I will investigate.
The py2dsc script seems to be obsoleted by the to-be “debian” command. Can you refer me to the source code and/or documentation for that command? I was not previously aware of it.
The pypi-install script seems dangerous to me, because downloading unverified software and putting it into the system seems a rather bad idead (a.k.a. “sudo ./setup.py install considered harmful”).
Yes, some might consider it dangerous, although it does of course require root privileges before installing anything system-wide (and only builds the .deb file with user privileges). Nevertheless, it is a useful tool and safer than "sudo python ./setup.py install" because one can always do "sudo dpkg --purge python-some-package" to remove that package again.
python-debian provides useful support code for generating and reading debian formats. A quick read show the code would benefit from some 2.6 modernizing (i.e. gain in simplicity and readability by using modern idioms and stdlib functions). Yes, I'm not particularly proud of the code in stdeb -- please feel free to hack away. Any and all improvements accepted, preferably in bite-sized commits to a fork on github.
Would using this package in stdeb / distutils2.command.debian instead of shelling out bring anything?
(Ah, I gather this is the debian command you refer to above?) Not knowing that command, I'm not sure what would be gained. If the command depends on debhelper (by shelling out to dh_make), it would remove that dependency. It also brings all the options described in the README.rst file. -Andrew
Hello again, and sorry for the hiatus
I see, thanks for pointing this out. I thought pkg_resources was in the stdlib (or on that track). I will investigate.
pkg_resources is not in the stdlib. The good ideas from it are moved into pkgutil as we speak <wink>, and will be in the standard library when distutils2 is merged back.
The py2dsc script seems to be obsoleted by the to-be “debian” command. Can you refer me to the source code and/or documentation for that command? I was not previously aware of it.
I’m sorry, I was referring to a future (“to-be”) distutils2 command based on your work.
The pypi-install script seems dangerous to me, because downloading unverified software and putting it into the system seems a rather bad idead (a.k.a. “sudo ./setup.py install considered harmful”). Yes, some might consider it dangerous, although it does of course require root privileges before installing anything system-wide (and only builds the .deb file with user privileges). Nevertheless, it is a useful tool and safer than "sudo python ./setup.py install" because one can always do "sudo dpkg --purge python-some-package" to remove that package again.
Well, I’m against sudo too (it trains unix beginners to type their password when asked, and we know that people don’t read text when they just want stuff done), and against doing too much with admin rights :) That said, unix philosophy is about consenting adults (a.k.a. “yes, you can shoot yourself in the foot”), and since dpkg is able to remove installed files, I have to agree with you that your script can be useful, at least to a class of users that don’t want to use the per-user site-packages directory (assuming they know about it). Also, note that there is ongoing effort to write a generic client to query PyPI, so Alexis (a GSoC student, like me) will probably be interested in your work. I see in stdeb’s README that there are at least two other projects with the same goals. Have you had the opportunity to make a comparison?
python-debian provides useful support code for generating and reading debian formats. A quick read show the code would benefit from some 2.6 modernizing (i.e. gain in simplicity and readability by using modern idioms and stdlib functions). Yes, I'm not particularly proud of the code in stdeb -- please feel free to hack away. Any and all improvements accepted, preferably in bite-sized commits to a fork on github.
I’ve looked at your code once, I think it would benefit from using distutils2. It’s a moving target right now though, perhaps polishing the requirements and waiting before coding is the safe option. Regarding debian-python, its code is under GPLv2 or v3, so inaccessible for Python’s stdlib. We may perhaps ask for relicensing of specific really helpful bits if needs be. Kind regards
participants (2)
-
Andrew Straw
-
Éric Araujo