Re: python-social-auth 0.2.19-1 review
Hi Dmitry, (Sorry for taking so long to reply.) On 1 June 2016 at 08:40, Dmitry Shachnev wrote: > Usually one would do both things using: > > git-dpm import-new-upstream --pristine-tar-commit /path/to/tarball > > In your case .git-dpm was inconsistent with upstream branch, so I had to > pass the additional --use-strange-upstream-branch argument to the above > command. > > Please use the instructions at https://wiki.debian.org/Python/GitPackaging > next time when i.e. importing a new upstream version. Had imported the new upstream version using "gbp". I'll use "git-dpm" from now on. > I have also pushed some packaging simplifications to Git, and also fixed > the KGB hook (s/sphinx/python-social-auth/). I totally forgot about passing "sphinxdoc" to "dh". Thanks for taking care of this. > I will upload the package later today. It is in testing already. Thank you very much! :-) > Also, I noticed that the comment about disabling tests in debian/rules is > out-of-date: the *requirements*.txt files depend on nose >= 1.2.1, which > should be OK (though there are hard dependencies on version numbers for > other packages). > > It would be nice to get the tests run during build again, if possible. I've tried to run the tests and looks like there's a problem with the dependencies: - "requirements.txt" specifies[1] "requests-oauthlib>=0.4.0" but when running the tests on Python 2.7, it asks for "requests-oauthlib>=0.6.1", which is specified[2] in "requirements-python3.txt". Not sure why one superseded the other. - "python-saml==2.1.3" is specified[3] in "social/tests/requirements.txt", which suggests that it is a test-only dependency. But under "social/backends/saml.py" there are a few imports[4] from "onelogin.saml2.*", which makes me think that there's a missing runtime dependency. Am I misunderstanding something here or there's really a confusion regarding the dependencies? Regards, Tiago. [1]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/tree/requirements.txt?id=b2df566#n4 [2]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/tree/requirements-python3.txt?id=b2df566#n4 [3]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/tree/social/tests/requirements.txt?id=b2df566#n9 [4]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/tree/social/backends/saml.py?id=b2df566#n10 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: python-social-auth 0.2.19-1 review
Dmitry and Michael, On 24 May 2016 at 07:08, Tiago Ilieve wrote: > Thinking about this, the best solution seems to be drop the patch and > remove the "site/" folder, repacking it as a DSFG-compatible tarball. > But if there isn't a strictly legal requirement (e.g. to include > sources for files that aren't distributed in binary form), I'm not > sure this worth the effort. At first I thought this would be hard[1], but following the example from "python-docutils"[2][3] proved to be quite straightforward. I've pushed the changes[4], but there are two related things that I didn't figured how to do properly: - Commit the repackaged tarball contents in the "upstream" branch and create a tag named with "+dfsg" suffix. Is "gbp import-orig" able to do this by itself? - Add "pristine-tar" data for the repackaged tarball. This could probably be done when solving the previous question. If you guys can kindly take a look, I'd appreciate. Regards, Tiago. [1]: https://wiki.debian.org/BenFinney/software/repack [2]: https://sources.debian.net/src/python-docutils/0.12%2Bdfsg-1/debian/copyright/ [3]: https://sources.debian.net/src/python-docutils/0.12%2Bdfsg-1/debian/watch/ [4]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/commit/?id=65fd5ed -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: python-social-auth 0.2.19-1 review
Hi Dmitry, On 21 May 2016 at 05:47, Dmitry Shachnev wrote: > I think it's better to put the missing sources in debian/missing-sources/ > directory rather than patching them in. > > (That is also suggested by the Lintian error description[1], and should > make that error disappear.) The pedantic warning is actually "source-contains-prebuilt-javascript-object", not a "source-is-missing" error. This solution won't apply to this case. Looking through the files, there are some interesting details: - "0001-append-uncompressed-bootstrap-as-its-source.patch" won't apply. The uncompressed JS/CSS files were previously added[1] directly to the upstream "site/" folder. Does this configures as a Debian Policy violation? - The "site/" folder isn't included (or used at all) in the binary packages. What happened is that upstream decided to include the project website in the same repository. Should we really worry about its contents? Thinking about this, the best solution seems to be drop the patch and remove the "site/" folder, repacking it as a DSFG-compatible tarball. But if there isn't a strictly legal requirement (e.g. to include sources for files that aren't distributed in binary form), I'm not sure this worth the effort. > According to the copyright format specification[2]: > > | There are many versions[3] of the MIT license. Please use Expat[4] instead, > | when it matches. At first I thought this was clarifying and confusing at the same time, but now I got it. It's not that the "MIT License" is a wrong name for it, but a non-ambiguous one. Fixed[2] and sorry for insisting on it. I hadn't figured that "MIT" wasn't a valid short name under the machine-readable format. Regards, Tiago. [1]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/commit/?id=71c4050 [2]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/commit/?id=1a445da -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: python-social-auth 0.2.19-1 review
Hi Michael, On 19 May 2016 at 08:41, Michael Fladischer wrote: > my quick review after building it: > > - lintian complains about site/js/bootstrap.min.js, AFAIKT the "site" > folder contains the project's website. Maybe you would like to remove > it by repacking the source tarball. There's a patch[1] adding sources for bootstrap CSS/JS minified files, but this doesn't makes much sense, right? They aren't included in binary, nor the orig source tarball. I can repack it as a DSFG-compatible tarball, but would like to receive a second opinion about the mentioned patch, confirming if it is really useless. > - You could shorten "python-all (>= 2.7~)" from Build-Depends to > "python-all". Noticed but somehow forgot about it later. Done[2]. > - It's more accurate to use "Expat" instead of "MIT" in d/copyright. I respectfully disagree with you at this point, as I had already talked about it on "debian-mentors" last month[3]. In this case there's even an additional detail: the copyrighted files specifically uses the "MIT" name for the license. Using a different name under "debian/copyright" would be an inconsistency. > - Both binary packages ship the documentation. While it's only a few KB > it would be an option to move the documentation to a separate binary > package. Nice catch. I've added a separate binary package for the documentation[4] and built it as HTML instead of text (Debian Policy Manual, §12.4 Preferred documentation formats[5]). > Cheers and thanks for your work! You're welcome. Thanks a lot for your review. :-) [1]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/tree/debian/patches/0001-append-uncompressed-bootstrap-as-its-source.patch?id=f94ec2c [2]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/commit/?id=f4543a1 [3]: https://lists.debian.org/debian-mentors/2016/04/msg00060.html [4]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git/commit/?id=f94ec2c [5]: https://www.debian.org/doc/debian-policy/ch-docs.html#s12.4 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
python-social-auth 0.2.19-1 review
Hi DPMT, In my first task as a member of the Debian Python Modules Team, I've prepared an upload of "python-social-auth"[1]. It was updated to a newer upstream release (0.2.13 to 0.2.19) and some fixes were also done. Is there anyone here able to review/sponsor those changes? Regards, Tiago. [1]: https://anonscm.debian.org/git/python-modules/packages/python-social-auth.git -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Request to join Debian Python Modules Team
Hi Piotr, On 16 May 2016 at 18:48, Piotr Ożarowski wrote: > welcome :) Thank you very much for accepting my application. Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Request to join Debian Python Modules Team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I want to join the Debian Python Modules Team (DPMT), bringing the package "python-path-and-address" to it and maintaining others that are under the team's umbrella. There's a ready-to-be-uploaded version of "python-social-auth"[1] waiting permission to be pushed to Alioth, which I'll be then asking for sponsorship. My Alioth login is "myhro-guest". I have read the Debian Python Modules Team Policy[2] and accept it. Regards, Tiago. [1]: https://github.com/myhro/deb-python-social-auth/commit/6f5c8a4 [2]: https://python-modules.alioth.debian.org/policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJXNYy+AAoJEAbChazvkyV6sDEQAIbryK5fEuNa4h8xbZ0ji1Nb sDeP9ny03tT3ak1xCCTghapsW/+M2uiBxZqqPn4zBR/fkh7PSPji5z4jWAXvspdu aPCcEioa/6p9bz5zaCnIyhzeZ9r1nHy69x0eT7jnu/cQiKkrP0EOXLsD5YIFlTOk b3lHHmTWewuS0loYUXsUKvUTG8x1vLV58LBqh3Po8EoJDQ2WceoRi42DaKzWGG8K VJkV2ZIUCAmtkqK7w9Sf2uuNfe4GLQc7djDu29bNLHAjpBP6ehsN8ypxJKhbvawe EZKeWGIOw8OQeJHVEI3t5f/o6BucFuw2EElwPwi1A7W03e1cVYasGheoJI0ryCD8 GXDQ4rlGVmIlYqq0Bfx5XdwKKzUqmY6iq0csTWz0n6xfGevvyn29AAj7E6Ag3nUr VV9fW8E3DDlAu8sui84eY64lSlSjnHtQOKg0GYiS+YJo1knLNa+1Z7e9hKoAXT/J sB6LQLQs93CvLqu2nzCm1lUsipX6ziKSKBzxNitYJzHtqRh9I1covFUE6rTqVppW OeoAdiXSM1RKH9jP6OdxsIG01IFExePU2xrvT/5s+Ah13J5T7wRcG2sCn0aDUVn9 K7ULP8mU5PBIyB0D95mNiUTwI9FasCrsLdbYq3LrDN+S5e0YcD5PBhjAaFEBQbHu cEYYdRsj3A/XuX1vE34T =wSja -END PGP SIGNATURE-
Re: Properly splitting Python "-doc" packages
Piotr, On 14 April 2016 at 18:28, Piotr Ożarowski wrote: > if you decide to go this way, please use python-bootstrapvz, not > python-bootstrap-vz (module name is bootstrapvz, not bootstrap-vz) > > I copy-pasted your typo in package name so dh_python2 didn't find the > right directory and didn't do its job. > > See attached patch (now it uses private dir) I've reverted[1] the package split and make a few changes based on your patch. Nice to see that it wasn't working because of a typo and not anything more serious. I also like the idea of not hardcoding a Python version (even a Python 2 one) in some "install" file path, as now could be changed from "usr/lib/python2.7/dist-packages/" to "usr/share/". Thanks again for the help and the patch. - Ben, On 15 April 2016 at 00:57, Ben Finney wrote: > Is there really a need for this separation? If the Python modules are > installed to an application-private directory, then by definition they > will not be publicly importable. So the Python libraries don't make much > sense as a separately installable package. Mostly because of the problem that I faced earlier, where the package hadn't worked as I expected because of the "*.pyc" file. Turns out that this was caused by a typo spotted by Piotr. The package is now being properly in a private application directory. Regards, Tiago. [1]: https://anonscm.debian.org/git/cloud/bootstrap-vz.git/commit/?id=c25f5cc8dd70456fb25e87f68419c553059e -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Properly splitting Python "-doc" packages
Piotr, On 14 April 2016 at 12:33, Piotr Ożarowski wrote: > PYBUILD_NAME is used to guess the Debian binary package name (and that's > THE only thing it is used for), whatever is in setup.py doesn't matter. > > If you use PYBUILD_NAME=foo, it will install into: > > debian/python-foo/# python2.X and python2.X-dbg > debian/python3-foo/ # python3.X and python3.X-dbg > debian/pypy-foo/ # pypy > > that's all, there's no more magic with PYBUILD_NAME Got it. Thanks for the explanation. > then PLEASE PLEASE PLEASE do not install as public modules - install into > /usr/share/boostrap-vz/ f.e. with this pybuild args: > > export PYBUILD_INSTALL_ARGS=--install-lib=/usr/share/boostrap-vz/ > --install-scripts=/usr/share/boostrap-vz/ > > and > > /usr/share/boostrap-vz/boostrap-vz /usr/bin/boostrap-vz > /usr/share/boostrap-vz/boostrap-remote /usr/bin/boostrap-remote > /usr/share/boostrap-vz/boostrap-server /usr/bin/boostrap-server > > in debian/boostrap-vz.links > > see PYBUILD_INSTALL_ARGS above (and use PYBUILD_DESTDIR=debian/bootstrap-vz/ > instead of PYBUILD_NAME) Ok. As this seems to be considered very wrong, I've separated the package[1], between "bootstrap-vz" and "python-bootstrap-vz". The first one contains binaries/man pages/etc. and the later contains the library with everything packaged by Pybuild. I've tried to use "/usr/share/boostrap-vz" for it, but as it run as root it ends up writing "*.pyc" files in there, resulting in a non-clean package removal. I guess the split between application and library package is a better form of organization. Thanks for your help and your awesome work in Pybuild! Regards, Tiago. [1]: https://anonscm.debian.org/git/cloud/bootstrap-vz.git/commit/?id=1c075a7c300fa541abe2ccdcf8c5ab35128f7a76 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Properly splitting Python "-doc" packages
Hi Piotr, On 14 April 2016 at 10:52, Piotr Ożarowski wrote: > that's because python-django is using --buildsystem=pybuild in dh; if you add > > export PYBUILD_NAME=bootstrapvz > > it will install .py / egg-info files into python-bootstrapvz binary package > (please add python-bootstrapvz binary package, BTW) I had made a test with Pybuild, but ended up facing the same problem. Now I see that the problem is that the variable "PYBUILD_NAME" should have a value of "bootstrap-vz" (notice the hyphen), not "boostrapvz". Probably because this has to be consistent with whatever is the package name defined in "setup.py", right? Anyway, if the package is named "python-boostrapvz" it ended up properly packaging the files, but as I've mentioned here a couple times before[1][2], I don't want to call any Python application package as "python-*". bootstrap-vz is a CLI application and should end up in a package named "bootstrap-vz". The problem is that if I do this, I'll and up with an empty binary package package again. Is there a way to tell Pybuild that the Python files should end up in the package "bootstrap-vz" and not "python-bootstrap-vz"? > "usr/lib/python*/dist-packages/bootstrapvz/" in bootstrap-vz.install > doesn't match /usr/lib/python2.7/dist-packages/bootstrap_vz-0.9.5.egg-info, > add this line if you want egg-info to be included: > > /usr/lib/python*/dist-packages/bootstrap_vz-*.egg-info/ If I can fix the package name mentioned above, Pybuild will add the "*.egg-info/" folder as well. Regards, Tiago. [1]: https://lists.debian.org/debian-python/2016/04/msg00017.html [2]: https://lists.debian.org/debian-python/2016/04/msg00027.html -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Properly splitting Python "-doc" packages
Hi, I was working on the "boostrap-vz" package and noticed something really annoying when creating a "boostrap-vz-doc"[1] binary package with its Sphinx documentation: the actual Python files that composes the application weren't being packaged on the main "boostrap-vz" one. I had to add "usr/lib/python*/dist-packages/bootstrapvz/" to its "debian/boostrap-vz.install"[2] to fix this, but I feel this is wrong. Looking at other Python packages that have separate "-doc" packages, like "python-django", they don't seem to need this. Also, its "*.egg-info/" folder also went missing, as we can see with "debdiff": Files in first .deb but not in second - -rw-r--r-- root/root /usr/lib/python2.7/dist-packages/bootstrap_vz-0.9.5.egg-info/PKG-INFO -rw-r--r-- root/root /usr/lib/python2.7/dist-packages/bootstrap_vz-0.9.5.egg-info/dependency_links.txt -rw-r--r-- root/root /usr/lib/python2.7/dist-packages/bootstrap_vz-0.9.5.egg-info/entry_points.txt -rw-r--r-- root/root /usr/lib/python2.7/dist-packages/bootstrap_vz-0.9.5.egg-info/requires.txt -rw-r--r-- root/root /usr/lib/python2.7/dist-packages/bootstrap_vz-0.9.5.egg-info/top_level.txt This broke its entry point scripts (at least I finally find out the cause of the "pkg_resources.DistributionNotFound" error), so I had to either add custom ones[3] or add "usr/lib/python2.7/dist-packages/bootstrap_vz-*.egg-info/" to its "debian/boostrap-vz.install" file as well. Any ideas on what I missed here? Regards, Tiago. [1]: https://anonscm.debian.org/git/cloud/bootstrap-vz.git/commit/?id=899e841f89d17418de77e5d7f56ff48627415e79 [2]: https://anonscm.debian.org/git/cloud/bootstrap-vz.git/commit/?id=7d0cf538f8e806f83529b3b7cad9af3ee93cca42 [3]: https://anonscm.debian.org/git/cloud/bootstrap-vz.git/commit/?id=d8ec5b17af1f96d9b1221963abf5abc3ef087900 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging Grip
Hi Dmitry, On 6 April 2016 at 17:21, Dmitry Shachnev wrote: > 1. Public (/usr/lib/python*/dist-packages) vs private (/usr/share/) location > depends on whether the module is intended to be used by third-party packages, > or only by grip itself. > > 2. The Style Guide doesn't *require* both Python 2 and 3. The Python 3 > package is required, but add the Python 2 one only if you really need it. > > 3. If you decide to ship files in a public location (dist-packages), then > the package having those files should be named python3-something, not > just 'grip'. > > 4. Setuptools-generated entry points for public modules are fine, but for > private ones it's better to use your own ones or symlinks. > > Hope that answers your questions. Thanks for taking the time to explain me this, but actually I got a little bit confused. Because yes, what you said is consistent with what I found on articles about Python packaging on wiki.d.o[1][2], but at the same time there are well-known packages in the archive that contradicts this, specially the item "3". The package that I used as an example is tox. It used to be called "python-tox", which is now a transitional dummy package[3]. Now is named "tox"[4], because it is intended to be used as a CLI application, but at the same time it ships its files in "dist-packages"[5]. I followed the tox example and named the package "grip", not "python-grip", because I'm standing on the shoulders of giants here. I don't really know its maintainer, Barry Warsaw, but the guy has both "@debian.org" and "@python.org" e-mail addresses[6], so he clearly knows about Debian packaging and the Python ecosystem itself way more than I do. The problem with the item number "4" is that I never got it working as intended. So every time I have to create my own "/usr/bin/" scripts or symlinks, discarding those auto-generated entry point scripts. Regards, Tiago. [1]: https://wiki.debian.org/Python/LibraryStyleGuide [2]: https://wiki.debian.org/Python/AppStyleGuide [3]: https://packages.debian.org/sid/python-tox [4]: https://packages.debian.org/sid/tox [5]: https://packages.debian.org/sid/all/tox/filelist [6]: https://qa.debian.org/developer.php?login=barry -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Bug#820029: RFS: grip/4.1.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "grip" * Package name: grip Version : 4.1.0-1 Upstream Author : Joe Esposito * URL : https://github.com/joeyespo/grip * License : MIT Section : utils It builds those binary packages: grip - Preview GitHub Markdown files like Readme locally To access further information about this package, please visit the following URL: http://mentors.debian.net/package/grip Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/grip/grip_4.1.0-1.dsc - This package depends on "python-path-and-address" (RFS #819773[1]), which is not on the archive yet. It would be awesome if the sponsor could help me with both RFS bugs. Tests are commented out in "debian/rules" because they depend on a newer version of "python-responses". I've filled a bug (#820020[2]) which is now pending (thanks Ondrej Novy!). This can be fixed as soon as the updated package hits unstable. Decisions made about packaging layout (Python application vs. Python library) have been clarified on the "debian-python" mailing list[3]. I also would like to thanks Gustavo Panizzo, who gave me permission[4] to take over his ITP. Regards, Tiago. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819773 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820020 [3]: https://lists.debian.org/debian-python/2016/04/msg00017.html [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611#17 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging Grip
Hi, The Style Guide for Packaging Python Libraries[1] states that in cases like this, one should package the library for both Python 2 and 3, creating a third package that contains the executable. As this package is indeed intended to be used as a CLI application (as its description says), I've followed the examples found in packages like python-django and tox and: - Didn't used the application layout which stores files in "/usr/share/", as it has modules that needs to be imported later; - Removed the entry point script that is automatically created; - Added a custom and simple script[2] that imports and calls Grip's main function; - Ended up with a single package called "grip". As I said, I didn't invented this and followed the practices that are being used by bigger Python packages. I'm entirely open about discussing those decisions with my future sponsor in the RFS that I'll be filling later today. Regards, Tiago. [1]: https://wiki.debian.org/Python/LibraryStyleGuide#Executables_and_library_packages [2]: https://github.com/myhro/deb-grip/blob/0fc1143/debian/bin/grip -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: running tests against installed version of package
Hi Brian, On 2 April 2016 at 22:32, Brian May wrote: > This will only test the current version of Python 3. Which is OK at the > moment, there is only Python 3.5 > > However it was very useful to have packages run tests against Python 3.5 > while Python 3.4 was still the default. > > I imagine the same thing will happen when Python 3.6 is released. I see. Actually I've removed the "override_dh_auto_test"[1] when I found out[2] that Pybuild can to do this by itself. Now I wonder whether this is enough to fit the use case of multiple Python 3 versions that you mentioned... Regards, Tiago. [1]: https://anonscm.debian.org/git/collab-maint/python-path-and-address.git/commit/?h=debian/unstable&id=9b57cbf [2]: https://wiki.debian.org/Python/LibraryStyleGuide#Overriding -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: running tests against installed version of package
Thomas, On 31 March 2016 at 18:49, Thomas Goirand wrote: > Most of the time, you get by this doing: > PYTHONPATH=$(CURDIR) python -m pytest tests Awesome tip! Just stumbled up on this one when imports where changed from relative to absolute and this tip properly fixed the matter. Piotr, On 31 March 2016 at 19:13, Piotr Ożarowski wrote: > this will test python2.7 only and will most probably ignore extensions, etc. I've used the following workaround for this. override_dh_auto_test: PYTHONPATH=$(CURDIR) py.test PYTHONPATH=$(CURDIR) py.test-3 ... As Python's "unittest discover" weren't working anyway. Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "python-path-and-address" * Package name: python-path-and-address Version : 1.0.0-1 Upstream Author : Joe Esposito * URL : https://github.com/joeyespo/path-and-address * License : MIT Section : python It builds those binary packages: python-path-and-address - Functions for server CLI applications used by humans. (Python 2) python3-path-and-address - Functions for server CLI applications used by humans. (Python 3) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-path-and-address Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-path-and-address/python-path-and-address_1.0.0-1.dsc - This package is a dependency of Grip[1], which is also being packaged (ITP bug #790611[2]). Regards, Tiago. [1]: https://github.com/joeyespo/grip [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Packaging Grip
Hi, I'm packaging grip[1] (ITP #790611[2]) and have a few doubts: Should I package it as an application or a library? It is really a CLI application, but when called it imports its main function as a module[3]. I can't use its entry point script directly because it expects to be installed using easy-install, raising an error when called: pkg_resources.DistributionNotFound: The 'grip==4.1.0' distribution was not found and is required by the application I can easily deal with this removing this entry point script, adding execution permissions to the "__main__.py" file and linking it to /usr/bin/grip. I've looked at the "python-django" source and it installs[4] a custom script[5] that decides if "django-admin" should be called with Python 2 or 3. I'm supposed to use this approach, as I guess both Python versions should be supported when packaging it as a module? What I mean is: is there a best practice when dealing with entry point scripts? Or any approach is fine as long as it that calls the correct script as the main binary? I've consulted the Debian Python Policy and didn't found an answer. Regards, Tiago. [1]: https://github.com/joeyespo/grip [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611 [3]: https://github.com/joeyespo/grip/blob/v4.1.0/grip/__main__.py [4]: http://sources.debian.net/src/python-django/1.9.4-1/debian/python-django-common.install/ [5]: http://sources.debian.net/src/python-django/1.9.4-1/debian/django-admin/ -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging pythonpy
Dmitry, On 31 March 2016 at 15:54, Dmitry Shachnev wrote: > Cool, one little change and it's much better! Actually this has one big implication: as it uses the same interpreter to evaluate its input, it becomes compatible with Python 3 expressions only. Noticed that after trying to access "string.letters" which was renamed to "string.ascii_letters". Added a note to the manpage[1]. > Now that you've changed to Python 3, you need to change the shebang from > python2 to python3 anyway… That's true. > This command works for me (as a DEP-8 test): > > python3 ./test/test_pythonpy.py -v > > Unfortunately dh runs tests before install/link phase, so we cannot run it > during build (without ugly hacks). Though if upstream adds an option to > specify path to executable used by tests, it will help a lot. I'll leave this upstream contribution as a future improvement, OK? This way we can get the package going in its current state. > Ok, if you add the DEP-8 test (just one 3-lines file), I'll sponsor it. > (If you prefer to wait for a new upstream release, I don't mind of course.) Awesome news! I've imported[2] the new upstream version and added DEP-8 tests[3]. The updated package is on mentors.d.n[4] (with no warnings at all) and its source was pushed to collab-maint[5]. > One small suggestion: if you are using pybuild, you can simplify the install > command a bit: > > dh_auto_install -- --install-args "--install-lib=/usr/share/pythonpy > --install-scripts=/usr/share/pythonpy" > > It's a bit shorter because you don't need to specify --install-layout and > --root. This is way simpler. Thanks for the tip. Done[6]. > Also, don't you think that /usr/bin/py is too generic? Maybe use > /usr/bin/pythonpy or something similar instead? (It's easy to change that, > as the linking is done by packaging rather than upstream buildsystem). It is indeed pretty short and generic, but is the way upstream have been distributing it since the beginning (the project is nearly two years old), so I guess it would be a hassle if we change it right now. I've triple-checked if it wasn't colliding with another binary name and it isn't. Also, if it is called "pythonpy" or something like that, would be somewhat annoying to use completion, as every time someone hits "pyt" it would end with "python" first. On 31 March 2016 at 16:31, Florent Rougon wrote: > Especially considering that 'py' is the name chosen for the Python > Launcher for Windows by upstream Python developers : I wasn't aware of that. Thanks for point this out. Regards, Tiago. [1]: https://github.com/myhro/deb-pythonpy/commit/bdb7aeb [2]: https://github.com/myhro/deb-pythonpy/commit/093b63a [3]: https://github.com/myhro/deb-pythonpy/commit/8f74394 [4]: http://mentors.debian.net/package/pythonpy [5]: https://anonscm.debian.org/git/collab-maint/pythonpy.git [6]: https://github.com/myhro/deb-pythonpy/commit/c6f0d79 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging pythonpy
Dmitry, On 30 March 2016 at 16:48, Dmitry Shachnev wrote: > Looks like I was a bit mistaken — dh_python2 will not replace shebangs for > files in /usr/share. But then you can do this manually using a sed call [1], > that is still easier than a patch. This is indeed way clever than an entire patch to fix something so simple. :-) Done[1]. > Re Lintian error, this looks like a false positive. See [2]. You mean that maybe it's better if we add an override instead of a workaround? > Minor nit about your package: please build-depend on dh-python to get a modern > version of dh_python2. Done[2]. > Major nit about your package: did you read the Python policy, in particular > the part that tells that all new packages should use Python 3 [3]? Actually I had consulted it, but not read it entirely. I don't know why but I thought that the Python 3 requirement was a *nice to have*, not a *should have*. Anyway, I've updated[3] the build system to use Python 3. I noticed that the test suite wasn't being properly executed and sent a patch to upstream[4]. As soon as a new release is made with this changed integrated, I'll be adding support for DEP-8 (as suggested by Barry Warsaw[5] in the last week), as they are functional tests that depends on the package being installed. I've uploaded the updated package to mentors.d.n[6], but I guess its better to wait for a new release integrating the test suite fixes. The upstream is pretty fast and responsive. Are you able to sponsor the upload when we finish taking care of those details? I've filled an RFS (#819289[7]), but forgot to add the "debian-python" mailing list in "X-Debbugs-CC". Regards, Tiago. [1]: https://github.com/myhro/deb-pythonpy/commit/f4ce711 [2]: https://github.com/myhro/deb-pythonpy/commit/868667b [3]: https://github.com/myhro/deb-pythonpy/commit/3c2f4bd [4]: https://github.com/Russell91/pythonpy/pull/79 [5]: https://lists.debian.org/debian-python/2016/03/msg00101.html [6]: http://mentors.debian.net/package/pythonpy [7]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819289 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging pythonpy
Hi Dmitry, On 29 March 2016 at 18:40, Dmitry Shachnev wrote: > You do not need a patch for this kind of thing. Just pass > --shebang=/usr/bin/whatever to dh_python2 call in your debian/rules. > > Also, for debian/packages, /usr/bin/pythonX is preferred over /usr/bin/env > pythonX. Thanks for the tip. I've tried to remove the referred patch and added "--shebang=/usr/bin/python" to the already existing "override_dh_python2". The problem is that with this modification the error "python-script-but-no-python-dep" comes up again. :-( Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging pythonpy
Gianfranco, On 25 March 2016 at 19:07, Gianfranco Costamagna wrote: > up to your sponsor :) Tried one or two new approaches and it didn't worked. In the I've created a patch[1] changing "#!/usr/bin/env python2" to "#!/usr/bin/env python". This should work as long as Python 2 is the default interpreter, something which may change in the next years, but isn't a problem at least for Stretch. I'm all in for another options if someone doesn't like this patch. > swap Files: debian/* > and Files: * > > first the more comprehensive and later the less. > (lintian might be more specific) This is awesome. I would never figure out by myself that it was so simple to fix. :-) > I did fix the python apps in blah section with section "utils", and uploaded > on debomatic again. > Now that lintian warning is not there anymore. Yup. I've did that as well[2]. > (I won't download the package, I think I already answered the points) No problem. You answers were very helpful, as always. I've uploaded a new version of the package to mentors.d.n[3]. There are the following lintian messages now: * "newer-standards-version": which can be ignored, as mentors.d.n doesn't consider 3.9.7 as the current standard. * "debian-watch-file-is-missing" and "no-upstream-changelog": which will be fixed in the near future with upstream help regarding tagged releases. * "binary-without-manpage": which I'll be fixing, adding a manpage before submitting an RFS. Thank you very much, Gianfranco! Regards, Tiago. [1]: https://github.com/myhro/deb-pythonpy/commit/5450656 [2]: https://github.com/myhro/deb-pythonpy/commit/0e2d987 [3]: http://mentors.debian.net/package/pythonpy -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Packaging pythonpy
Hi Gianfranco,
On 25 March 2016 at 16:21, Gianfranco Costamagna
wrote:
> http://debomatic-amd64.debian.net/distribution#unstable/pythonpy/0.4.4-1/lintian
> please dget it from there and start again :)
>
> I fixed a lot of issues, and many more are there now!
I really appreciate your effort in trying to package it yourself, but
you didn't solved the main problem, which is the
"python-script-but-no-python-dep".
The "dh_auto_install" override is used to place it in
"/usr/share/pythonpy" which is the proper place for Python
*applications*[1]. Without it, it goes to the place where *libraries*
should be located.
The "remove_entry_points_scripts.patch" avoids the creation of
py{2,2.7} binaries that aren't needed. Without it and removing the
override for "dh_fixperms", the package becomes useless. There's no
way to call the "py" command, as its main script doesn't have
execution permissions.
Looks like it would be way easier to fix the entry point scripts to
created a binary named "py", avoiding just the other ones. We can also
ignore the override that changes the target folder, but doing this
feels wrong, is like we are ignoring the best practices for packaging
Python applications. That's why I'm wrecking my head with this issue,
removing every file that would be useless, instead of following the
easiest path.
About the lintian output:
* "unused-file-paragraph-in-dep5-copyright": this info doesn't appear
even when I run lintian with the same arguments on my machine. This is
strange, as I'm running "v2.5.42.1" from sid and debomatic-amd64.d.n
is using "v2.5.42.1~bpo8+1", which should be the same version. Do you
know how can I do this?
* "debian-watch-file-is-missing": this is right. I've asked[2]
upstream to tag every release on GitHub, so we can fetch information
about new versions from there.
* "application-in-library-section": fixed[3].
* "no-upstream-changelog": the upstream added a changelog file in the
last version (0.4.9, which I have packaged this afternoon), but it
doesn't comes with the tarball available in PyPI. This will be solved
when the releases are tagged and we grab them from GitHub.
* "package-installs-into-obsolete-dir": fixed using dh_bash-completion[4].
I've uploaded the last (0.4.9-1) package version to mentors.d.n[5].
Thanks,
Tiago.
[1]: https://wiki.debian.org/Python/Packaging#Example_2:_Python_application
[2]: https://github.com/Russell91/pythonpy/issues/76
[3]: https://github.com/myhro/deb-pythonpy/commit/0e2d987
[4]: https://github.com/myhro/deb-pythonpy/commit/954e424
[5]: http://mentors.debian.net/package/pythonpy
--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil
Re: Packaging pythonpy
Hi Gianfranco,
On 25 March 2016 at 06:25, Gianfranco Costamagna
wrote:
>
> adding python to the dependencies?
> do you have python to build dependencies, dh-python and python:Depends on the
> binary package?
This is what is strange. I've made the following changes:
-
diff --git a/debian/control b/debian/control
index f0c1b3f..5205298 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,7 @@ Section: python
Priority: optional
Maintainer: Tiago Ilieve
Build-Depends: debhelper (>= 9),
+ dh-python,
python (>= 2.7.3),
python-setuptools (>= 0.6.24)
Standards-Version: 3.9.7
@@ -13,7 +14,9 @@ Vcs-Browser: https://github.com/myhro/deb-pythonpy
Package: pythonpy
Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
+Depends: python (>= 2.7.3),
+ ${misc:Depends},
+ ${python:Depends}
Description: 'python -c', with tab completion and shorthand
pythonpy is an utility that facilitates the usage of Python one-liners. The
command 'py' evaluates a string consisting of any Python expression. It can do
-
But this didn't helped at all. The lintian.d.o page for
"python-script-but-no-python-dep"[1] says:
"Packages with Python scripts should depend on the package python.
Those with scripts that specify a specific version of Python must
depend on that version of Python (exactly).
For example, if a script in the package uses #!/usr/bin/python, the
package needs a dependency on python. If a script uses
#!/usr/bin/python2.6, the package needs a dependency on python2.6. A
dependency on python (>= 2.6) is not correct, since later versions of
Python may not provide the /usr/bin/python2.6 binary."
What is the "exactly" version of Python for a script which has
"#!/usr/bin/env python2" as its shebang?
> it is generated *during/after* the build, so the clean target won't work.
>
> a "package.pyremove" file might help, not sure
>
> codesearch.debian.net might help
> egg path:pyremove$
>
> https://codesearch.debian.net/results/egg%20path%3Apyremove%24/page_0
"pyremove" didn't worked, but in the same page that I found references
to it[2], there's a suggestion to override "dh_python", which is what
I did[3]. Thanks for the suggestion. :-)
Regards,
Tiago.
[1]: https://lintian.debian.org/tags/python-script-but-no-python-dep.html
[2]:
https://wiki.debian.org/Python/LibraryStyleGuide#Python_3.3.2F3.4_unittest_fixers_for_2to3
[3]: https://github.com/myhro/deb-pythonpy/commit/68db18e
--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil
Re: Packaging pythonpy
Hi, Can someone please help me on this one? I'm pretty close to finish the initial packaging work. After fixing the following issues, it will be a matter of adding a manpage and filling a RFS. * How to fix the "python-script-but-no-python-dep" lintian error? I've tried with and without pybuild and the error still persists. * How to get rid of the ".egg-info/" folder that is being packaged? Looks like "debian/clean" rules aren't working. There's a GitHub repository for the package[1]. I have intention on asking for a repository on collab-maint when the package is ready (I have write permissions to it). Regards, Tiago. [1]: https://github.com/myhro/deb-pythonpy -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Fwd: Packaging pythonpy
Hi Debian Python Applications Packaging Team, I'm forwarding this message because it should have been asked on "debian-python" mailing list as well. The first message of this thread[1] is on "debian-mentors". Regards, Tiago. [1]: https://lists.debian.org/debian-mentors/2016/03/msg00223.html -- Forwarded message -- From: Tiago Ilieve Date: 11 March 2016 at 11:55 Subject: Re: Packaging pythonpy To: debian-ment...@lists.debian.org Hi Ben, On 10 March 2016 at 22:19, Ben Finney wrote: > Not by itself. You need to run something that will actually use that > substitution variable. > > By default you should be using Pybuild in new packages for Python code. > This will bring many benefits, including interpolate the substvars for > Python. Following the Pybuild wiki page[1], I've added "dh-python" as a build dependency and added the following to "debian/rules": diff --git a/debian/rules b/debian/rules index cc0781a..ae03e14 100755 --- a/debian/rules +++ b/debian/rules @@ -1,7 +1,10 @@ #!/usr/bin/make -f +export PYBUILD_NAME=pythonpy + %: - dh $@ --with python2 + dh $@ --with python2 --buildsystem=pybuild override_dh_auto_build: But that doesn't changed anything. The "python-script-but-no-python-dep" error still persists. Am I missing something here? > Still needed. Build dependencies are not affected by Debhelper. If the > build depends on ‘foo’, use of Debhelper won't take away the need to > declare “Build-Depends: foo”. Got it. > That directory is effectively auto-generated garbage for a Debian > package, it needs to be cleaned. > > Use the ‘clean’ target to remove files you don't need. Debhelper's > ‘dh_clean’ is useful here, see its man page. The Python FAQ wiki page has a section about "debian/clean" and Python eggs[2], which I was already following. What is strange is that the upstream tarball has five files in its ".egg-info/" folder: - dependency_links.txt - entry_points.txt - PKG-INFO - SOURCES.txt - top_level.txt But the built package has only three: - dependency_links.txt - PKG-INFO - top_level.txt So, it looks like the original files are being properly removed, but are created again later. Any idea about how to overcome this? Regards, Tiago. [1]: https://wiki.debian.org/Python/Pybuild [2]: https://wiki.debian.org/Python/FAQ#How_should_we_package_Python_eggs.3F -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
