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
Attachment:
signature.asc
Description: PGP signature