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

Re: Packaging pythonpy

[Tiago Ilieve]

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