Re: Bug#827873: RFP: python-pytz -- World timezone definitions, modern and historical
[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
Re: Python package providing both modules and an app
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: Python package providing both modules and an app
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 >https://www.python.org/dev/peps/pep-0366/>. 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 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
Python program as a command-line program (was: Python package providing both modules and an app)
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
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 > >https://www.python.org/dev/peps/pep-0366/>. 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
