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