Maintenance of new Flask extensions
Hi DPMT, I would like to package and maintain some Flask extensions. Flask, a web micro-framework, and some extensions for it are already available in Debian and under team maintenance of the DPMT. I would initially like to add these two extensions: Flask-Restless Flask-Compress Flask-LDAPConn Also, I would like to help fix open bugs in existing Flask packages. I would base my packages off of existing ones in order to enable the team to co-maintain the packages. Apart from these new packages, I maintain a few other packages in Debian, in cooperation with several DDs. If the DPMT is willing to co-maintain the new packages, I would like to keep the package repositories and the like in DPMT from the beginning. Please tell me if it is ok to ask for team membership on Alioth ☺! My username there is natureshadow-guest. Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Mobil: +49-1520-1981389 Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Contributor LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: This is a digitally signed message part.
Re: Maintenance of new Flask extensions
Hi Ondrej, > I'm Flask Debian packaging maintainer. Not much to do with packaging, but > help is always welcome. > > > I would initially like to add these two extensions: > > Flask-Restless > > Flask-Compress > > Flask-LDAPConn > > go ahead and pack it under DPMT. Alright, thanks! > > > Also, I would like to help fix open bugs in existing Flask packages. > > which bugs? Flask package is bug-free :) > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=flask I wasn't talking about Flask core, but the other extensions packaged in Debian. Flask-RESTful, for example, has some open RC bugs and is marked for autoremoval from testing. > > If the DPMT is willing to co-maintain the new packages, I would like to keep > > the package repositories and the like in DPMT from the beginning. > > every help is welcome! > > > Please tell me if it is ok to ask for team membership on Alioth ☺! My > > username > > there is natureshadow-guest. > > https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin I have tried to request team membership, and found that I already requested that (probably some years ago) and the request is still pending. > > Thanks for your interest, maybe you could join our IRC (#debian-python). My > nickname is onovy. Joined it ☺. Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Mobil: +49-1520-1981389 Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Contributor LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: This is a digitally signed message part.
Acceptance of team policy
Hi, of course, I have read and accept the DPMT policy. I have also already workde with gbp in the way described in the policy. Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Mobil: +49-1520-1981389 Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Contributor LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: This is a digitally signed message part.
Bug#833920: ITP: flask-restless -- Flask extension which provides simple generation of ReSTful JSON APIs
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: flask-restless Version : 1.0.0b1 Upstream Author : Jeffrey Finkelstein * URL : https://github.com/jfinkels/flask-restless * License : BSD or AGPLv3+ Programming Lang: Python Description : Flask extension which provides simple generation of ReSTful JSON APIs Flask-Restless is a Flask extension that provides simple generation of ReSTful APIs that satisfy the JSON API specification given database models defined using SQLAlchemy (or Flask-SQLAlchemy). I intend to maintain the package within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJXqxErMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYjLg//Q5Lx+NuPAf0YcHNw1QIy bnh2tH5Qwd1sJ3nwTl4JYdDecUL5sm8m7oEBPThD/5uOi7Hu6e27W4P5x+YRCGTy uBfu03n+btzCP85rTgQBINbbK3RpIxIiXOGf2WbKwHyex+ibTW6DzuHZ5otvLeJI Ag6q+oRLOoTnqOjYWc3ul9uNw8U+pRpvig1KXQEN8XzwL3cPWLEA5vn5R001e0rh vwKkvMv45ehzYhxlhwfSxrxIem28cs6q4U3BINXKOJj2t1HrN7PmYjQsprPY+z+D hLg6zg3IsQlLAoWSDIjA9liwshNnf0IQzdtlDh32E/HwEnQp2UhPoSsuST1cuKiE zwCjF2G4M4x+zQIsqg2xIrMRYr3OmWCqqAOrg7WzCM75hdF5iiSUEjIoGuD2sVl2 hO6zKOwiRbBWRgqj69+PxYL2mAOMewXGTmI21fd3PoXItU9yVFZ0cKX58VpqfmP7 lHxJvBO0fcLpxJ6bUk48GJG/fffsY5zAwwbdhlJgNNGmeCdHtU4OUfeMIngJwJ7v kNHNIrUeGqtM89sYZ316RVGquRD7XPfpiywphSwE12G/4j6Zm6r/wOifQZYI2LML cqcdZ4vNWVFMMoxfOUqGK+F8QVvxwGCooKq83IOm1FjCVM18JiF8L+xpQ0BS8yV9 1uhUG5WybIpIH2XnOBd2ycA= =k0lG -END PGP SIGNATURE-
Bug#833921: ITP: flask-compress -- Compress responses in your Flask app with gzip
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: flask-compress Version : 1.3.0 Upstream Author : William Fagan * URL : https://github.com/wichitacode/flask-compress * License : MIT Programming Lang: Python Description : Compress responses in your Flask app with gzip Flask-Compress allows you to easily compress your Flask application's responses with gzip. The preferred solution is to have a server (like Nginx) automatically compress the static files for you. If you don't have that option Flask-Compress will solve the problem for you. In intend to maintain the package within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJXqxMoMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paToA/+PKT9Bm9JXiTKbbyGZg9R 3QXR6ulc7BpihiPHpBQTt8nFKZGhuCyTxkJfQPnx/uZLGHqV72tmqyNLA2P9EgT3 gc3Nbst1BpsuU/WSavGYSJR+maxPD63ITCGM1fzzAW0gAzK6D5WWBqrkdIN/2qnx r6kgrOQVd1smsU3eSvfyyE2GoUpIsEiM0iulajG1I4ETReJcE2cKeFsPb248fHPe djM8w48AIy7bEjBkuuHB++d75OxIytSBo9ltVnOqtJoYJUp6bZzFL8aHQe2hzQK9 rFBtRNcXvTnZOhZqismtgLnHv1Yb855mJR5JHHUGGvPURiUprnopR3KSQdq29gvT AhG77A+0lEb2MXii4jOo6xc8Aqud5+ZCYdrAESL/vf1phDKyUbIYeURZ+VrFNtJJ LKZbyZzC+Js596CBw6E3yofoeBdElwo/3AMbDUcRXgqzmXInzzwqCcFiTpuXNynZ jWU7YLSufuHj7K1LV7mFffNu1fgcfTFVGu+beDfV6OQvBM6QOapZXITRzDs0F+Iy 2PFqRk3CUG+yA1uIFarpI5LsRVZgAd0H0dzxbZ0vPzri21lKdb1g2jPgwgMJCdK3 9kL8Z2x9JF0hVOmYeNstmwUtyvIZa2SC2WxqzhlYqTz4dAqbv9cmp4e1Rnqu7Dwe 4b7ZbmmENi+Tl1jcpE+H97I= =xDZt -END PGP SIGNATURE-
Bug#833922: ITP: flask-ldapconn -- LDAP connection and ORM for Flask Applications
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: flask-ldapconn Version : 0.6.13 Upstream Author : Rafael Römhild * URL : http://github.com/rroemhild/flask-ldapconn * License : BSD Programming Lang: Python Description : LDAP connection and ORM for Flask Applications Flask-LDAPConn is a Flask extension providing ldap3 (an LDAP V3 pure Python client) connection for accessing LDAP servers. To abstract access to LDAP data this extension provides a simple ORM model. In intend to maintain the package within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJXqxRKMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYpfg//Yev9If4IafH30athGAqf AySEtCUlRv7/nfchHl+b62V5aXWQzu7LPzqrLlsuTKsPJm6UFun3uWb78REFKEGD Ah/37lLRgQn5gTgwqSeksUBcS/PhiZ//1S8yHl4HCEVDfnWvlFiqiYQdizX+PGDj zwQnJxvQFoqkUdZnbUqjccAa1dWQZw/hNwSQAs+SbrdxT8jKGdznE6TsMLh0tWS0 SmF7KkVko4G/uQz100UdNqiyVobv9HxiKAgMvhMjLSMNF6d7IGyLKYr4bVP3tl7g P4chtX3tNHeJyx9i+w6SG9kefRoZjS5SIxyfP1p/dTcgoEVS7eTHo/jEBRFCSLty c/W7eImwkb9dwhamDMP+56IgTOcNcyljZddqsqqrY1nfnqJj0QhOhfDlurpo/aBX DyAuwVwatv70wSpL1kF25RNzz00PohYvkUdxabXs81538u0Z4PYZDKB+It+7nlGx FNM2YkahgIhFFApWjmDKAZJFwIR+LOrcTflTKbJdjjyA+5xy5rIqHPnn7bnD9Reo h914PHP7pZEQb3cJhzjvBcbIPoQJrYEe3M69j+deQAnjTJcFmXX+/ragP9/KJpU7 DV+m/tJQeeX/mhB03u9I7gtZGlWOKS02dThVjQA9XTvN5o/t64HeeTtUKcHUi8XX sGaBkO6rVjcSE3Gi1QKPy0Y= =AmnQ -END PGP SIGNATURE-
Review/sponsorship of osmalchemy package
Hi, I would like to ask for review and sponsorship of the osmalchemy package. It can be found in the usual place at: git.debian.org:/git/python-modules/packages/osmalchemy.git The package can be build with gbp using pristine-tar. It appears to be lintian-clean, apart from a missing upstream changelog (which upstream, i.e. me, myself and I, will fix in a future release ;)). OSMAlchemy will be used in several projects that will run on Debian; it was also feaured at the Python Unconference in Germany last weekend and many people like it and would like to use it, so adding it to Debian seems legit (it has also a quite low impact on the repo, as it has only few dependencies, so nothing bad to expect there). Thanks in advance for looking at the package, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Mobil: +49-1520-1981389 Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Contributor LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: This is a digitally signed message part.
Bug#838566: RFS: mimerender/0.6.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package "mimerender" * Package name: mimerender Version : 0.6.0-1 Upstream Author : Martin Blech * URL : https://github.com/martinblech/mimerender * License : MIT Section : python It builds those binary packages: python-mimerender - RESTful HTTP Content Negotiation for web frameworks (Python 2) python3-mimerender - RESTful HTTP Content Negotiation for web frameworks (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mimerender Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mimerender/mimerender_0.6.0-1.dsc The package is a dependency of the soon to be added flask-restless package. Regards, Dominik George -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX49MdMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW 5VcP/2d2QeKrmW4BjHgi/f47zf6sPuyaCI/J+K5LkIEo1giM09XGyXGj+qmJQgE1 o+PtW+Mgmzb2y+4SP8Oil39Rzs3w7DQd/2V8xV/MvrbWnnymQh2aqmv4r5aW4GKS N4TLMfKm0yPkEljg6e6tByG7RtFaIwwYD26j3qq6E8yn5FYVbQJZLQee222AeLVA U6L1JJvk+dwDW52HvS8yHjKexj5RxE34fRpJ3NFS82bHzUCRTY/mtB3SEqOHWBqf X23+LIjx0YcSM4/6Phe5ZZ1YhSPby5wtdHAvPBVLKo/SAvbrSzX02zeAzcrwm/vO AqNjAlReydi6p2WOrkWGj9yCQbTf/xMe/0RPY9HL+SuAOXjh5Fkwixj3WI/BXAUs mbGBPOfI9Kn9g88sVreVtnyaJmIJBGt++VjRCHlp3AOjkR+0rUTJFjrjTyNJEtIM CVrayIKxpOe8ozAWZRZPP7e/KoQDux3FPK643lQEf+f/n3tHTLmVoumTkspc5cWo nTCSdpBhL+SiOvI7o7IwyKFcr9CZMwSVY81cVpbhOipcQLVLbYrIvyJsoXDJHMOd Cu1Tj/PybMfcSeMxs+4cj3JWRmh1oDxpKjVSGZjumc0qlBr+sftGHfSQBSfJLJck /zLyIJpmxCjdMiUtElQsROBRusKD5ypnpIbWH6vZ780/4hqx =fkb9 -END PGP SIGNATURE-
Bug#838575: RFS: flask-compress/1.3.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package "flask-compress" * Package name: flask-compress Version : 1.3.1-1 Upstream Author : William Fagan * URL : https://github.com/libwilliam/flask-compress * License : MIT Section : python It builds those binary packages: python-flask-compress - Compress responses in a Flask app with gzip (Python 2) python3-flask-compress - Compress responses in a Flask app with gzip (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/flask-compress Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/flask-compress/flask-compress_1.3.1-1.dsc Flask-Compress is an extension for the popular Flask micro-framework for web applications. Regards, Dominik George -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX4/Q2MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW EHQP/RlBk46ylNURHGc+Q9S1GznIsFC60YH+sEq1Kb0jZ+go2sDRCO6zoQBG06OH 19OQxa+u/KVdlw23J78sckeFC9Q/Z5vmGKG9f73SfEBSwkwJT1jJLJCr66OyXu1j RYvD1yebcHMGDuvVkK8NOHN+Trd4TA9EA9OG3DGMLRlj5jbkmEoayH1VP4J/kSZd 3Cn3RqwKifACCTOzRuQzUik5rE5rQ+5pBHFdkZM8zRkjwHxWDOmKcGp6+2uYx2ep Qu9GH2nZsuQF/+Quw9etiU1f9K3Dj872SpOU78zCHtjsxlYEmOlsmi1vCK89JDDp kobKTwc9mXiG/aTevKhJBPmaT4JTmKSNXk1gJUxiTaHPnDK+W3J2MSUODJAf4Yzd +kaz5lLAh3iLeiFloowVSZ78QhZAboaaRpoZrJ4DlDahMupkflHpj9q72f0RvFIq NLR4sm44D2xegYLOjJdYVYMXxANoSQM9nYGU/vgNBUiihE+z7tR143zyJT2Lya9m pJWlbaGLMyIVm0UmGJnNFom+vcuElrlEo6m9Gx5sJCi8bjbPfeL4OIhmQW1KNFd4 3duqOAYDQUzlvrdSOIzsuuWqAV8xvmgFIRJcLREE4QVj9TyDwayXDUdu+TGkI7Ib yA0XIvXulNrs3VZ4pfhv2dzG/JuJI2CjrTni+7i+Zjf71LWH =jWru -END PGP SIGNATURE-
Bug#838576: RFS: osmalchemy/0.1.post1-1 [ITP]
Package: sponsorship-requests Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package "osmalchemy" * Package name: osmalchemy Version : 0.1.post1-1 Upstream Author : Dominik George * URL : https://github.com/Veripeditus/OSMAlchemy * License : MIT Section : python It builds those binary packages: python3-osmalchemy - OpenStreetMap to SQLAlchemy bridge To access further information about this package, please visit the following URL: https://mentors.debian.net/package/osmalchemy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/osmalchemy/osmalchemy_0.1.post1-1.dsc Regards, Dominik George -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX4/UNMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW kpIP/0g1QFaADFn6TSzlrz/EJbLxBXcSwQJXEz9gLIk6jApvd8rCmOh+/YGc0Vsc VGVCjFV/V4Ok05EY02dhRrhq+4mWo556OYczM91z6ueY4ZrVKEdrNssAem8z3bJT yuHmFVPIVFIOEq2z1qfn8RdTypI2kr73obqd2ZQNbJA7PZBx3ymcl9iI00c0pn6J 8z3nGQqeJLZtR7clEwCoERX9U+pw5yhyedrZFHX0iDiY70rjxLGIqR7GD4SeNZcp PtMBf49EGiO/fzBRAQ7dC0hd/+ZHtfLvwv+TKe3uYmaaQIqPnDU4TLeC6bvfeuPc PRAONJ7kXui+++3Jb3KStz5WsfkG8xFH28LGIZ8mgTQkMbmvTwjRXl2PcnKH8N+B rjNutKfl0YXjcyQsYtNfsRGvEen8Dka+vSe9/NOPciwufZ3OMfcHA4nB3fU5+FoV Yh0Y0T/FOt41Gu9j14vF4n8jkS4osBRY10xuIApG/MDgfX1ajiKpunvkgRps1Mss vZ6Dtl0piBleBfKdvLGUr0y8vg5eW0Zfurh/cUn3NEHOIXXFhPvWcYNuvT8rz9mA 6CAftH7ZdV7d8TLKdtGyU2VnyCaCLxyJgBPgxZc/e08BJYP/jeKPzMtVpYIF79oC P3Llk4C3Lrvf4jQOgpL/x6oW5dB+hioR5RP9dMBrzY9D+cW7 =1HcA -END PGP SIGNATURE-
Bug#838581: ITP: python-testing.mysqld -- Python unit testing helper for temporary MySQL databases
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-testing.mysqld Version : 1.4.0 Upstream Author : Takeshi Komiya * URL : https://github.com/tk0miya/testing.mysqld * License : Apache Programming Lang: Python Description : Python unit testing helper for temporary MySQL databases The testing.mysqld package is a helper module for unit testing Python database applications. It provides methods for setting up, maintaing, and cleaning up a MySQL database server that can be used within a test suite. A real MySQL server is started as an instance in a temporary directory and removed after running the tests. The package would enable Debian package builds to use it and to enable unit tests of Python packages that use databases. Right now, the only way to build packages that do is to disable the tests. The package shall be maintained within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX5APJMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW M0EP+QEsX9hTVtToT3gkYdJnQ0qYo5SxmM+vtDjreWwQC+pWB2XdnXPtzheIifAi dJkbxT7n1UmndsroPkKiay9Qhhs/i+k/maAdArTTOKG93KmZGmXw7+L87XqavGa0 hdMWnc7rFqAmgg6KAyQb0NjT4TZvtwetGvkTRDwFyWSlbeXS91dK9zTAtaAU31Jv W5hh+ec+72bOdg7d5usut+KcwmiYXQcX2cTD9VAwSdM5dk13LUzvXffXn9pQTWc1 zEtCMKDLaqtB3do+95kZwjFQW+ynd4XfKyCsQdB3MuVn4rc+Ruc87mHijUI6Uhys a1xvNbVNM3WtP0QBNi4b93MLZt7kOdGB9fGvMnSr2X6dLmwcW83jochBC629UhIU fW/CMPGnZ/DwarMerov8j71rUv3tv01LI2FkLlF/oXDkh5Ni6l2sCDljfv4gtM8O yAXKJsU5HOX1gc7KOdE+BI5Ws6k4qiRQUf7UWouLRuZVs2fvj1C6ntLxz7mkoTuQ bvpZpTGLweGzzsl0/9A301Ooxpg+f1DxH2TI6BpRWA9t2XLqabsCW+8gBdAGmnQs yE99tuWmqAQ3tsZCU0/1cPf0dym4Ir6jOKd6n2EjwvAMb2I5glG2VL8/WXeF1hNN 4p8kazlWHTFUiCrnrLyQjbuL7V29wekjKCv3vhYo2NVE1JJx =eAUz -END PGP SIGNATURE-
Bug#838582: ITP: python-testing.postgresql -- Python unit testing helper for temporary PostgreSQL databases
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-testing.postgresql Version : 1.3.0 Upstream Author : Takeshi Komiya * URL : https://github.com/tk0miya/testing.postgresql * License : Apache Programming Lang: Python Description : Python unit testing helper for temporary PostgreSQL databases The testing.postgresql package is a helper module for unit testing Python database applications. It provides methods for setting up, maintaing, and cleaning up a PostgreSQL database server that can be used within a test suite. A real PostgreSQL server is started as an instance in a temporary directory and removed after running the tests. The package would enable Debian package builds to use it and to enable unit tests of Python packages that use databases. Right now, the only way to build packages that do is to disable the tests. The package shall be maintained within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX5ASeMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW OC4P+wVDTvdt+ISFXMWyu0odDl/Kqjyx7jBxdBN3aSxjyhKpKyIvTyOYUU+wPSxe fhEPeZM+OBeKYOxzclr5Scal2D64enL8k77cNGxw0hzQ2EaIGhStDE5Cxz8OJmuT RnMEWQpHo2/PEkIsW8VVeu4oAPHkk+/gCoVXOYxwyxmtBPZWxLkvyjzHq6B2Q07h 7avdjrvdI15G5ASi27XFHoadGIV3toGIwzVRKqvAe2zTIlSgeFtQhgDKTIi0VfqO D77+cIm/AMKWdrzWlTNtDA68QMAtqt3TGGo7lFHNETY7yrOZdPJwK1EgHAvX7NrC 3xH0PrOLu7WvQ3+0bLAlTtBRIJGxKbvMizqnNGwGeRJUHcWeexpahQczNy27CC9q RlSiT8IfgGMouPRP7xJaqH1eg6SIhXxZ5FbI3K/k+L6xVI/Mo83q+w6VBKTzjRVf TSTcSbDWQNnDc2yCpZ0vNI/1sth3jQKvtjgE4ARahlHIHLsjzpulzTA2/du3e931 NN+lJlTyz1Jp4yFXR2o/XazIn/VsoQtC5+LMy0RzyJE1Kjjs60iaGtFhRo34LrR1 StxwR8PhuK/hJluAN0Ufg6jLXPX7XGrZhSzgVugGbW2q9/jufcPtZbcXdtt/eD8V J9zLKV5N9nvT/nx2JtP4C5DsIbHrT3FTd6qY/wxmpq/Qt7zE =WzUS -END PGP SIGNATURE-
Bug#838587: ITP: python-testing.common.database -- Utilities for Python testing.* modules
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-testing.common.database Version : 2.0.0 Upstream Author : Takeshi Komiya * URL : https://github.com/tk0miya/testing.common.database * License : Apache Programming Lang: Python Description : Utilities for Python testing.* modules This package provides common utilities for some Python unit testing modules that handle database tests. Right now, two major test modules are known: testing.mysqld and testing.postgresql. The package shall be maintained inside the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJX5AwLMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW DRsQALPk23qalpioBK5geJfr/Lgo7t2svsmpdFaHQzixvEyJK3twJ8b5enXM8AJR Gd1GKGyvW+0qKTbrin4UNmP/LaynGQ1ZH63uE3rZ0VSzREi6b1ZjHd/vGKBjnq6m 77SSHRT5xkdg6mwjG19fQDx16vBn2qcEXiOZrwyjNaMD1k9T2xNBx/G8GzfIeZnD 0t0u3lIsDYU9ZpcE0GvUMi8zbUjRStUUMAEc3tnkvcz31lR7hA1xxjvWM5myY+ff LVWA2vu+MQ5EvEJQrPjBfmKlIr+o32Nrc9BgoLkddm4Ol3ehhY9MuF2PI0U9f7nY ZkidIkw6E42b94h/nA80i2VHHSMLbmZITReA5+s+nUvuv0is47Ymo1Z6UD5zIBZD I1TXSMofkINsZKmkoSWmRXWq3lGRp8N+/ifw/4wSMPpiqrioH4OkeW9cogczx0KR 4yVg5muZz8UzVNBoj45dY49UluqEPbVNzd+bB9OJMd5X4y/ELwT7nFzF0PrB/d8Y rUlfSC2m16eAu1aa19zWGRgLK0DHc7IPcbz2lOaPe5K2TEoC47oEbxDxsiMfo3Mp trL+aI+cuAmYHQhoMA+YLuRTBriwjZ4auxYOBgSnV34dn5N3V2MSofaBOmyhZdJK l7aQ1IYOErnhjoWq4miHHxLA3WclyI1VgYHImaPq+eUTvpzM =tkW5 -END PGP SIGNATURE-
Bug#843158: ITP: gpxpy -- GPX file parser and GPS track manipulation library
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: gpxpy Version : 1.1.1 Upstream Author : Tomo Krajina * URL : http://www.trackprofiler.com/gpxpy/index.html * License : Apache Programming Lang: Python Description : GPX file parser and GPS track manipulation library gpxpy is a simple Python library for parsing and manipulating GPX files. GPX is an XML based format for GPS tracks. . The library also contains utility functions that are used in GPX file handling, but can also be used separately, e.g. simple functions for calculating geographical coordinates. The package shall be maintained inside the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJYHHOWMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW B0IQAL+ktbh5pDNo0fc//HC8AMOf2qybGXZgPl7CDyXEMNuMaY3AvzDOFXKOAC0B Xt+grZF06HcMIxCNVwpyn3KeHWbtXAPzbVUzASyBfb6lFj2UQ3zKUD7zFiiY4rwn NqmIK3BIJ9wV7OtS2mcCInd/i+umQzQR3G4XVhB9Yn/7MpzzIfOqctnduT0Bvzyy ry+lhUQWp/I5/uXb3QmKYKXaO7cdweudkqiqLj9hi8QpmVsgCk8Q45vFxZk+iuOr seObj46NmlInluS0BvAvWZR8RBdUbxufrbQvYDSN2FDycGQQi4eHaUgIibGwyX96 5ZS1LAiAf4yuCAr76/VCXtk6auqPiJLgZi89lARIrYP5o4CnPdOZfa1611UXIdXt Am2w5ZWmOpQkljjsL1HfcNJqcD9AtLck6k4zyv1vqOvIaRInml1l7EEiZPM1TPFM nSADDSCyatywWOLAeZCg9nvU+Ud4gdWVEeAKadLQUXbgeCSDlqzrOKxc7AlsFmUg m41GAJP48Ov5RsuhCzU7dC3PQnQBBIPoQ7z35m0dp75SwWKmAVMCke/6jQIqkz8X UPY0Wj1Y9XYkF6932EKGn3tNEJiady2rYdfTrv/P0xYksLGhSiOZ2DQDdgCb0miS abkZXXdYus5fKrYb46xYtoT1B1Dx7X6ujwCPJXw0Tf4eyKmG =lJUx -END PGP SIGNATURE-
Re: How to split modules in multiple deb packages
Hi, > Hello everybody, I'm packaging a daemon that I've developed in python3 and I > need to split the core modules in two deb packages, but I don't now how to do > that. > > One of the module is specific for Raspberry Pi, it adds some > functionalities, but > the daemon itself doesn't require a Pi hardware and can still do its job > without that module even on a Pi. What I want to do is to split the modules > in two deb packages, one with all the modules except rpi.py and one with only > rpi.py (setting the appropriate dependencies, i.e. python3-gpiozero, etc). > > How can I do that? Well, in that case, with you being upstream, I'd separate the two packages entirely. > I can exclude rpi.py module from main package and create a > python3-mypackage.rpi.install > file installing rpi.py in /usr/lib/python3/mypackage but I don't think it is > the right way of doing that. Why not? > |-- mypackage/ > | |-- module1.py > | |-- module2.py > | |-- moduleN.py > | `-- rpi.py This is not a Python package. (Hint: no __init__.py…) > The MANIFEST.in > > include setup.py > > include MANIFEST.in > > recursive-include mypackage *.py > > include bin/mydaemon Uh? All of this is duplicating setup.py. Just remove it. Instead, please make sure to include your full licence, readme and changelog in the source tarball from within MANIFEST.in. -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
Re: How to split modules in multiple deb packages
Hi, > > Well, in that case, with you being upstream, I'd separate the two > > packages entirely. > > Yes, I can do that. But, don't you think a whole package for a single > python file is... too much? Well, is it? You were the one asking how to split it ;)… So, if you think the RPi and non-RPi parts should be separated, then separate them. If you think they shouldn't, then don't. I'd only suggest you make one decision, not two ;). > >> I can exclude rpi.py module from main package and create a > >> python3-mypackage.rpi.install > >> file installing rpi.py in /usr/lib/python3/mypackage but I don't think it > >> is > >> the right way of doing that. > > > > Why not? > > Because I'll miss all the "egg"-related files. Won't I? Well, you will, but that's correct. They only declare the Python package, not the modules it contains. And as your rpi sub-package would obviously depend on the main package, everything would be fine. You'd indeed go with namespace packages instead if you decided to separate the stuff upstream. > And, how can I choose the right destination folder? /usr/lib/python3 > or /usr/lib/python3.4 perhaps? By not using package.install, but copying the whole tree in override_dh_auto_install and the nremoving the non-RPi parts from the RPi copy of the tree. At least that's how I would do it if I had to. But, seeing that you are in doubt of your own decision to split the package: What about don't? Just make one package, period ;). In case you think you have to split the code because part of it will only run with python3-gpiozero, and python3-gpiozero is only available on armel, armhf and arm64, then you have other options: 1. Just make an architecture-dependent dependency on python3-gpiozero and just let the rpi module throw an ImportError it gpiozero is not available. No harm done, happens all the time, and would also happen if you'd not install it in the first place ;). 2. Find out that I am the python3-gpiozero maintainer, and kindly ask me to provide gpiozero on all architectures. It does have a mock GPIO implementation for testing purposes, if that's of any interest. So I'd personally go with 1. now and remove the architecture specification in the dependency once I got 2. finished. Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
Re: Implicit namespace packages (was: Re: How to split modules in multiple deb packages)
> > This is not a Python package. > > > > (Hint: no __init__.py…) > > Not required for Python3. > > https://www.python.org/dev/peps/pep-0420/ Yep, you're right. But that would still have to be declared in __init__.py to work properly, right? If not, that would be cool… -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
Re: Pending broken links
Hi, > I have noticed that the automatically generated links sent to the BTS on > git changes that close bugs are broken. > > e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855510#10 has the > following link: > > http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791 > True. For some reason, the redirect to gitweb on anonscm seems to be broken. This works correctly: http://git.debian.org/?p=python-modules/packages/slimit.git → https://anonscm.debian.org/gitweb/?p=python-modules/packages/slimit.git This doesn't and redirects to cgit instead, cutting off the commit id: http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791 → https://anonscm.debian.org/cgit/python-modules/packages/slimit.git/diff/?id= But… > Which generates the following error: > > 404 - No such project …following the above observation, it throws Bad object name instead here. -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Mobile: +49-1520-1981389 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
django-cms in Debian?
Hi, at Teckids, we are about to start using Django CMS for our website. We have a policy to only use Debian stable/main if at all possible. So I wonder whether there is a reason django-cms is not in Debian? (Apart from "noone started maintaining it" ;) In other words, before I start packaging django-cms and its missing dependencies, is there anything I should know? Cheers, Nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Phone: +49 228 92934581 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
Please add me on Salsa
Hi, please add me to the team(s) on Salsa. I am an existing DPMT member. Username: natureshadow-guest Thanks, Nik signature.asc Description: PGP signature
Re: the new PyPI, coming next month
Hi, > To be clear, PGP signatures can still be uploaded and they are still > available for download, they just don’t appear in the UI anymore. So, what does the pypi.debian.net redirector use for uscan? I imagine it used to scrape the website. Can it be changed to use the JSON API? > Longer term I’d *like* to get rid of PGP signatures, because I think > their value here is actually pretty low. I partially share this opinion, but that's a question to be discusses with the Debian policy people in general. While checking a GPG signature on the source tarball in general is a good idea, I am afraid some developers just drop any key they find on first glance into the package and are done with it, which actually provides nothing but a false sense of safety. > In that case they’d be replaced with TUF, but that’s a longer term > project. That one?: https://github.com/theupdateframework/tuf Well, I can only say *please* do not remove the possibility to upload signed source tarballs, but leave that to the developers! -nik -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Phone: +49 228 92934581 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. · Debian Developer LPIC-3 Linux Enterprise Professional (Security) signature.asc Description: PGP signature
Re: Future of pygame in Debian.
Hi, > pygame in Debian testing is currently python2 only, I am sure I am not > alone in thinking this is not a good state of affairs given that pygame is > frequently used for introducing people to programming. > > pygame in sid has python3 support but is held back from migrating to > testing by three rc bugs. None of which have had any response from the > maintainer. > > One of those is a FTBFS with python 3.7 which is apparently fixed > upstream. So presumably the best thing to do about this one would be to > update the package to the new upstream. I may have a go at this myself > but I'm not an expert in python packaging so I don't know how well I will > do. > > The other two are testsuite failures on architectures where frankly I > doubt pygame has many users*. I may also take a look at these after the > new upstream version is dealt with but I don't think it's worth putting > huge amounts of effort into pygame on architectures where I doubt it has > any users and I equally don't think it should be allowed to block the > availability of python3-pygame in testing on architectures people do > actually care about, so if the root cause cannot be found quickly I would > propose either disabling the tests on these architectures or requesting > the ftpmasters remove the binaries. > > Anyone have any comments or suggestions? Yes. I am the maintainer whom you accuse of not maintaining the package. Sorry to say that, but all your assumptions are wrong - all of the bugs you mention are handled, tagged accordingly in the BTS, new uploads are prepared in the packaging repository, and fixing last issues for the upload are being coordinated with upstream, keeping the buster release schedule in mind: https://github.com/pygame/pygame/issues/543 Anything more I can do for you? Cheers, Nik signature.asc Description: PGP signature
Re: Future of pygame in Debian.
Hi, > […] tagged accordingly in the BTS […] Oops, you are right. There are still two FTBFS bugs I failed to tag (but not to fix). Cheers, Nik signature.asc Description: PGP signature
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
Hi, > Could someone please upload this little package ? It's a dependency of > xsdata, an awesome XML/dataclasses library I'd like to get into the archive. I will check it tomorrow. -nik
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
Hi, > Could someone please upload this little package ? It's a dependency of > xsdata, an awesome XML/dataclasses library I'd like to get into the archive. uploaded, thanks for your contribution! One note: I'd consider watching for PyPI instead of GitHub. Cheers, Nik
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
> there was actually a recent discussion on this list, discouraging from > using PyPI in favor of github, since GH tarball usually contains docs, > tests, and other files useful when building from source, usually not > included in tarball released to users, ie pypi That's an upstream bug then, and upstream should fix that and ship a complete source tarball. I always submit pull requests updating MANIFEST.in and until now, all upstreams have accepted them. -nik
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
> and that will require an upstream new release, which does not help > when you want/need to package the current one Most upstreams kindly make . post releases immediately. Maybe I am just lucky with upstreams... -nik
Re: dh_python or pybuild
Hi, > I am not sure if I misunderstand something or if the documentation is > inconsistent. > > The PythonPolicy > https://www.debian.org/doc/packaging-manuals/python-policy/ > tells me that dh_python should be the preferred tool for packaging > (https://www.debian.org/doc/packaging-manuals/python-policy/#versions) > > But the LibraryStyleGuide > https://wiki.debian.org/Python/LibraryStyleGuide > tells me it is pybuild > (https://wiki.debian.org/Python/LibraryStyleGuide#Overview). > > And the DPT policy > https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst > tells me something about git-buildpackage and gbp. the three components work together, or better, are used at different stages. * git-buildpackage (which is the same as gbp) is used to manage the sources of your package in git * pybuild is the toolchain that does the building process itself, and knows how to run setup.py or other tools, etc. * dh_python is the debhelper chain, the glue between the package building process and pybuild dh_python can use several different build systems, of which pybuild is the preferred one. When debhelper calls, e.g. dh_auto_build, dh_auto_build calls all chains that support the build target. dh_python does, so it is called, and in turn calls pybuild to do its magic of figuring out how to do the build for your specific package at hand. HTH, Nik
Re: pygame 2?
Hi, > I'm wondering if anyone is working on bumping the pygame package to pygame > 2? I imagine there might be quite a few incompatibilities that would break > packages that depend on pygame, so perhaps an upload to experimental first > would make sense? I didn't have time to read up on the upgrade path, but will certainly do so for bookworm. -nik signature.asc Description: PGP signature
Re: PDM - Python package manager for Debian
Hi Carsten, > Or is there a way to get such packages build without a need for PDM to be > around? This should really not matter at all when packaging for Debian. The source tarball should include a setup.cfg or setup.py file (i.e. be a regular Python sdist), and if not developing on the package, you should never meet PDM. If the upstream sdist is not installable without PDM, this is probably an upstream bug; but my guess is that you chose a Git export instead of a real sdist as orig.tar.gz. -nik
Re: PDM - Python package manager for Debian
Hi, > I've compared the tarball from GH with the file from PyPi, the sdist on PyPi > contains even less files than the GH tarball, but also no setup.* files. Uh, PEP-517 actually allows that... I have never seen that in the wild. Cool, so this really means we will ultimately have to package everybody's homegrown build system now 🙄. -nik
Bug#1029076: uwsgi-plugin-python3: built against non-default libpython3.11 / should always build against the defalt Python in testing
Package: uwsgi-plugin-python3 Version: 2.0.21-3+b1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: debian-python@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Currently, the uWSGI Python 3 plugin is built against Python 3.11, and depends on libpython3.11. This is, to some extent, fine, as Python 3.11 is already in Debian. However, Python 3.10 is still the default Python in bookworm, and as it stands this will not change [1]. In practice, this means that without changing the interpreter and manually ensuring that the Python 3.11 environment is fully available, apps run through uWSGI do not work. So, the uWSGI plugin should in general always build against the default Python IMHO. - -nik [1] https://lists.debian.org/debian-python/2023/01/msg00010.html - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages uwsgi-plugin-python3 depends on: ii libc6 2.36-8 ii libpython3.11 3.11.1-2 ii uwsgi-core 2.0.21-3+b1 uwsgi-plugin-python3 recommends no packages. Versions of packages uwsgi-plugin-python3 suggests: pn python3-uwsgidecorators - -- no debconf information -BEGIN PGP SIGNATURE- iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCY8aedTEaaHR0cHM6Ly93 d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3ZDoAQCYW8oE4ZgiBKkgo1lge2Az 7/qTIXGHgKAAF5kmuGTB5QD+NiuAOboj6I6ZvxRZF4o1D3vXCBr1HkqYz+piZMQO Fgc= =Y+XX -END PGP SIGNATURE-
Re: Launchpad: Merge of Accounts Requested
Hi, >FYI: This message got delivered at the public mailing list >debian-python@lists.debian.org. To me it looks like someone if trying to find >a loophole in launchpad and plans to abuse the system. Thanks for reaching out to them. While at it, I'd also question why Canonical is scraping public repositories and creating user accounts for the scraped addresses. Yes, I know why they do it, but for me, it is another example of bad collaboration practice, on top of everything else to be said about Ubuntu (or more precisely, its owners). It's also small things that impose burdens on others, and if they think they need to fork Debian, copy packages from it (to put behind a paywall afterwards), then they certainly could do that without spoofing Debian people and team addresses. Disclaimer: I am assuming good faith in this specific case, but not in Canonical and Ubuntu in general. -nik
Re: Stop recommending PyPi as upstream for Debian Python packages?
Hi, >> Everyone has their own kink. I ignore Python modules that are not in >> Debian and others ignore Python modules not on PyPI. >> >> My reasons for ignoring PyPI: >> [long list of arguments] I somehow don't get the point here. Usually, I don't get to choose my build dependencies, so if an application I want to package depends on some module, I will have to package it. What point is there in discussing whether PyPI has a lot of crap around it, or whether it is a bad dependency? If an application I am packaging depends on a module and that module is low-quality or malware, what point is there in pulling it from GitHub instead? -nik
