Re: Packaging Grip

[Barry Warsaw]

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

[Dmitry Shachnev]

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

[Scott Kitterman]

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

[Tiago Ilieve]

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

[Dmitry Shachnev]

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

[Tiago Ilieve]

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

[Tiago Ilieve]

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