Re: Python package providing both modules and an app

[Ian Cordasco]

On Jun 22, 2016 7:54 PM, "Barry Warsaw"  wrote:
>
> On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:
>
> >This seems to be more common now that command-line invocation is
> >becoming even more discouraged. When the upstream documentation
> >recommends ‘python3 -m foo.bar’ as the primary means of invoking the
> >command line functionality, that really blurs the line between
> >command-line application versus library.
>
> Indeed.  It's true that -m invocation isn't as pretty as a /usr/bin
script,
> but it does have the advantage of unambiguously choosing the Python
version
> you want to run the script with.  How important that is depends on the
> application of course.
>
> >There is a compounding tendency to disparage ‘python3 ./foo/bar.py’,
> >which is subject to weird hacks and incomplete workarounds like
> >. I wish this trend could
> >be effectively reversed, because IMO this is a serious impediment to
> >considering Python a good choice for command-line scripting. But this is
> >all a digression, my apologies.
>
> Sorry, I don't quite understand the above.  Do you mean that you would
rather
> use `python3 ./foo/bar.py` more often and `python3 -m foo.bar` less often?
>
> In any case, thanks Hugo for choosing Python 3 as the version to use for
the
> /usr/bin script. :)

Speaking with my application developer hat on, the latter invocation
ideally helps the user be more aware of what version of Python they're
using.

This is beneficial in a couple cases:

- pip installing something: it's important for the user to know which
version of Python they're using

- running flake8 against a codebase. Flake8 relies on the version of
Python's AST for certain things. If the user is writing code with async
keywords but running Flake8 on Python 2.7, then they'll be in for a world
of unpleasantness.

By extension the same logic applies to any application that supports
multiple versions of Python but depends on things like the stdlib AST
module.

It's certainly a hideous invocation, but it has it's benefits.

Cheers,
Ian

Python program as a command-line program (was: Python package providing both modules and an app)

[Ben Finney]

Barry Warsaw  writes:

> On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:
>
> >There is a compounding tendency to disparage ‘python3 ./foo/bar.py’,
> >[…]. I wish this trend could be effectively reversed, because IMO
> >this is a serious impediment to considering Python a good choice for
> >command-line scripting.
>
> Sorry, I don't quite understand the above. Do you mean that you would
> rather use `python3 ./foo/bar.py` more often and `python3 -m foo.bar`
> less often?

When ‘./foo/bar.py’ has a shebang of ‘#! /usr/bin/python3’, and I invoke
that path as a command, the Unix shebang semantics turn that into
‘/usr/bin/python3 ./foo/bar.py’. Python will run the file as the main
module.

But invoking it that way runs into the nastiness and constraints
described in PEP 366 (primarily, relative imports break).

There isn't, AFAIK, anything portable that I can write in the shebang to
turn a command invocation of ‘./foo/bar.py’ into ‘python3 -m foo.bar’.

So yes, I expect Unix shebang semantics to work, and the fact that
design decisions in Python's import mechanism defeat that mode is an
impediment to using Python for writing command-line programs.

-- 
 \  “Dvorak users of the world flgkd!” —Kirsten Chevalier, |
  `\rec.humor.oracle.d |
_o__)  |
Ben Finney

Re: Python package providing both modules and an app

[Ben Finney]

Hugo Lefeuvre  writes:

> The entry point is generated by 'setup.py install_scripts', which is
> executed by pybuild after files specified in *.install have been
> installed (correct me if I'm wrong).

I haven't demonstrated for this case, but I would be surprised if that's
how it behaves. To my mind the ‘setup.py install’ command (and hence the
‘… install_scripts’ command) should be part of the ‘dh build’ sequence.

Again, someone should correct me if I'm wrong.

-- 
 \  “Holy polar ice sheet, Batman!” —Robin |
  `\   |
_o__)  |
Ben Finney

Re: Python package providing both modules and an app

[Barry Warsaw]

On Jun 22, 2016, at 11:25 AM, Ben Finney wrote:

>This seems to be more common now that command-line invocation is
>becoming even more discouraged. When the upstream documentation
>recommends ‘python3 -m foo.bar’ as the primary means of invoking the
>command line functionality, that really blurs the line between
>command-line application versus library.

Indeed.  It's true that -m invocation isn't as pretty as a /usr/bin script,
but it does have the advantage of unambiguously choosing the Python version
you want to run the script with.  How important that is depends on the
application of course.

>There is a compounding tendency to disparage ‘python3 ./foo/bar.py’,
>which is subject to weird hacks and incomplete workarounds like
>. I wish this trend could
>be effectively reversed, because IMO this is a serious impediment to
>considering Python a good choice for command-line scripting. But this is
>all a digression, my apologies.

Sorry, I don't quite understand the above.  Do you mean that you would rather
use `python3 ./foo/bar.py` more often and `python3 -m foo.bar` less often?

In any case, thanks Hugo for choosing Python 3 as the version to use for the
/usr/bin script. :)

Cheers,
-Barry

Re: Python package providing both modules and an app

[Hugo Lefeuvre]

Hi Ben,

> > The package is originally requested as a Python module[2] and it seems 
> > clear to me that the whole thing is only useful as a library
> 
> I don't understand this statement. If it is *only* useful as a library,
> why install the command-line entry point?

Indeed, I though about that, but python-slugify has been developed as an 
application[0] so I think it's rather a bad idea to completely ignore the 
entry point, even if it's not really useful. I think upstream would disagree, 
too. In my opinion, better build a third package, even if it won't be used
a lot.

> Why not install the command by using the configuration files for
> ‘dh_install(1)’; that is, specify in ‘debian/slugify.install’ the files
> to install.

The entry point is generated by 'setup.py install_scripts', which is executed
by pybuild after files specified in *.install have been installed (correct me 
if I'm wrong). So, I think that what you suggest won't work unless I write my 
own entry point, install it via debian/slugify.install and ignore those 
generated 
by setup.py. I think this would be even dirtier than what I already done. ;-)

[0] https://github.com/un33k/python-slugify

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E


signature.asc
Description: PGP signature

Re: Bug#827873: RFP: python-pytz -- World timezone definitions, modern and historical

[Piotr Ożarowski]

[Iain R. Learmonth, 2016-06-22]
> * Package name: python-pytz
>   Version : 2016.4
>   Upstream Author : Stuart Bishop
> * URL : http://pythonhosted.org/pytz
> * License : MIT
>   Programming Lang: Python
>   Description : World timezone definitions, modern and historical

already packaged as python{,3}-tz

hint: apt-file search /pytz/
-- 
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