Re: Packaging Grip
On Apr 06, 2016, at 11:48 PM, Scott Kitterman wrote: >In my opinion either can be correct depending on the primary purpose of the >package. I think that's true; take it on a case-by-case basis. In general, I like having a separate binary package for the /usr/bin script because it can be more easily discovered and because it can avoid confusion on library package naming. IOW, 'python-foo' is a library, not usually expecting it to contain a /usr/bin. As for entry points, I also like to use setuptools eps by default if they work. I had to ship a non-ep /usr/bin/pip because of bootstrapping issues. -Barry
Re: Packaging Grip
Hi Tiago, On Wed, Apr 06, 2016 at 11:37:24PM -0300, Tiago Ilieve wrote: > 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]. There are always exceptions of course. If the primary use of your package is its command-line interface, and you don't expect other packages in Debian to use its Python API, then shipping everything in one package called grip is probably fine. > 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. If upstream entry points don't work, then having your own ones is fine. Though in my experience upstream entry points for public packages usually worked. -- Dmitry Shachnev signature.asc Description: PGP signature
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
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: 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
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