Re: Packaging Grip
On April 6, 2016 10:37:24 PM EDT, Tiago Ilieve wrote:
>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.
It's not always clear what to do. I have done packages that started with
python{3}- that also ship scripts in /usr/bin if the module was the primary
purpose of the package. I've also not used python{3}- for packages that have
module in dist-packages when the /usr/bin script/application was the main point.
In my opinion either can be correct depending on the primary purpose of the
package.
Scott K
>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
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
request for alioth team
Hello guy, my name is Adrian i want to be part of the python-modules team in alioth i have a few pkgs in mentors for review and also i want to start fixing some of the pkgs that you have already, i did it for python-clicks and sent it to av...@debian.org but i want to start collaboration with the team. my allioth username is: alvesadrian-guest my python packages in mentors: python-daemonocle python-marshmallow tinydb python-flask-marshmallow I read and agree with https://python-modules.alioth.debian.org/policy.html
Re: Packaging Grip
Hi Tiago, On Mon, Apr 04, 2016 at 04:29:44PM -0300, Tiago Ilieve wrote: > 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. 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. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: running tests against installed version of package
[Thomas Goirand, 2016-04-06] > Don't use py.test-FOO, as this is deprecated. Instead, use something > like this: > > PYTHON3S:=$(shell py3versions -vr) > > override_dh_auto_test: > ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) > @echo "===> Running tests" > set -e ; set -x ; for i in 2.7 $(PYTHON3S) ; do \ > PYTHONPATH=. python$$i -m pytest ; \ > done > endif > > Note that you can hardcode 2.7, as we will keep this version for Python2 > basically forever (or until Python 2 completely dies), so it doesn't > really mater. hardcoding 2.7 is OK > Having multiple version of Py3 supported also helps backporting from Sid > to Jessie, and also supports future version of Py3 (as Brian wrote). > > Last, as Piotr wrote, PYTHONPATH=. isn't enough for non pure-python > stuff. In this type of case, there are other workarounds (which I can again, testing sources, even without extensions is not something we should do. If testing if all files are installed doesn't convince you, how about 2to3 changes not applied while testing Python 3.X? > tell if you need them). What I personally do is that I get things built > and installed within debian/tmp. That's the most easy way, a lot more > than double-guessing the build/* folder names. This also has the > advantage that the egg-info gets (re-)generated in the correct place. In > such case, you will want to do something like this: > > python setup.py install --install-layout=deb \ > --root=$(CURDIR)/debian/tmp > PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python2.7/dist-packages \ > PYTHONPATH=. python -m pytest > > Combine this with the loop for multiple version of Python above, and you > got (nearly) everything covered. ... and you will end up in debian/rules that is 5 times bigger than before and once pytest's interface changes, your package FTBFS - that's OK if you have time to update all your packages, but if you, like me, are lazy, then you can use "not very helpful for running tests" pybuild that does all above and more for you. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
