Re: Question about private modules in /usr/share
[Potter, Tim (Cloud Services), 2015-04-21] > binary gives an import error since /usr/share/dwarf isn’t in the PYTHONPATH: > > # dwarf > Traceback (most recent call last): > File "/usr/bin/dwarf", line 32, in > from dwarf import log # pylint: disable=W0611 > ImportError: No module named dwarf binary and module name are the same so distutils decided to copy script to module dir: | running install_scripts | copying build/scripts-2.7/dwarf -> debian/dwarf/usr/share/dwarf/dwarf | copying build/scripts-2.7/dwarf-manage -> debian/dwarf/usr/share/dwarf mv debian/dwarf/usr/share/dwarf/dwarf debian/dwarf/usr/share/dwarf/run in your install override, update symlink in debian/links and it should work -- 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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150421090124.gp2...@sar0.p1otr.com
Re: /usr/bin/python in Python 2 and 3
Hi, On Fri, 17 Apr 2015 17:11:45 -0400 (EDT), Geoffrey Thomas wrote: > I've written up the proposal I made a few days ago for a /usr/bin/python > launcher that keeps the API of being Python 2, but lets scripts opt in to > running on Python 3: > > https://ldpreload.com/blog/usr-bin-python-23 > > Let me know if you think this is a good or bad idea: I'll submit this as a > PEP as soon as we have rough consensus that this is a good idea. (We can > bikeshed the details once the idea itself is a draft PEP.) To be honest, I don't like this proposal. - Newly written code should *just* use Python 3 (there are exceptions, but very few). - If existing code supports Python 3, and its developers consider Python 3 as a target platform, then it should *just* use python3 shebang. Python 3 appeared seven years ago (at approximately the same time as Python 2.6, which is the minimal version for most bilingual code), so it is available almost everywhere. When the proposed PEP is accepted[1] and adopted by the distributions[2], the probability of *not* having Python 3 will be close to zero. - Existing code that has not been ported to Python 3 should continue to work (with Python 2), without any changes to it. These three cases cover most of the Python code. [1] which I hope will not happen [2] the next Debian release is no sooner than in 2017, nine years since the first Python 3 release -- Dmitry Shachnev, who is a bit slow on catching up with his mails. signature.asc Description: OpenPGP digital signature
Re: /usr/bin/python in Python 2 and 3
On Tue, 21 Apr 2015, Dmitry Shachnev wrote: To be honest, I don't like this proposal. - Newly written code should *just* use Python 3 (there are exceptions, but very few). - If existing code supports Python 3, and its developers consider Python 3 as a target platform, then it should *just* use python3 shebang. Python 3 appeared seven years ago (at approximately the same time as Python 2.6, which is the minimal version for most bilingual code), so it is available almost everywhere. When the proposed PEP is accepted[1] and adopted by the distributions[2], the probability of *not* having Python 3 will be close to zero. I agree with these, mostly. However, it's worth noting that "almost everywhere" today does not include, for instance, even the latest version of Mac OS X. Given how long it's been since Python 3 is out, are we confident that other OSes will add Python 3 by the next Debian release? For third parties who want to distribute scripts that run out-of-the-box everywhere (installers, cross-platform system management or monitoring scripts, build scripts, etc.), Python 3 isn't an option. If we remove Python 2 from the default install in Debian, Python 2 ceases to be an option too. So they'll start using sh or perl or something, or ship compiled code, both of which I think are net negative options. - Existing code that has not been ported to Python 3 should continue to work (with Python 2), without any changes to it. These three cases cover most of the Python code. This will probably cause all Debian systems in practice to get Python 2 installed on them at some point, with the possible exception of embedded / appliance-y systems that run one application and nothing more. If that's something we're fine with, sure (and it avoids the work of convincing third parties to add the pyversions= header and porting and testing on both versions). One other point that I glossed over: the interactive command "python" currently runs either Python 2 or nothing. Would we like it to run Python 3 at some point? If end users do this on their own via a symlink (which is very tempting) they'll get mysterious failures from certain third-party applications. A simpler version of the proposal is that interactive use (no arguments, and isatty(0)) always launches the latest Python interpreter of any major version, but all other use always launches the latest Python 2 interpreter, or prints an error message. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1504211029210.18...@cactuar.ldpreload.com
Re: /usr/bin/python in Python 2 and 3
On Apr 21, 2015, at 10:42 AM, Geoffrey Thomas wrote: >For third parties who want to distribute scripts that run out-of-the-box >everywhere (installers, cross-platform system management or monitoring >scripts, build scripts, etc.), Python 3 isn't an option. If we remove Python >2 from the default install in Debian, Python 2 ceases to be an option too. So >they'll start using sh or perl or something, or ship compiled code, both of >which I think are net negative options. Do you think that will happen even if Python 2 is just an apt-get away? >One other point that I glossed over: the interactive command "python" >currently runs either Python 2 or nothing. Would we like it to run Python 3 >at some point? If end users do this on their own via a symlink (which is very >tempting) they'll get mysterious failures from certain third-party >applications. That's the $64,000 question. :) >A simpler version of the proposal is that interactive use (no arguments, and >isatty(0)) always launches the latest Python interpreter of any major >version, but all other use always launches the latest Python 2 interpreter, >or prints an error message. Careful about `python -i`; that's essentially interactive use too. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2015042548.71594...@limelight.wooz.org
Re: /usr/bin/python in Python 2 and 3
On 21 April 2015 at 08:15, Barry Warsaw wrote: > >For third parties who want to distribute scripts that run out-of-the-box > >everywhere (installers, cross-platform system management or monitoring > >scripts, build scripts, etc.), Python 3 isn't an option. If we remove > Python > >2 from the default install in Debian, Python 2 ceases to be an option > too. So > >they'll start using sh or perl or something, or ship compiled code, both > of > >which I think are net negative options. > > Do you think that will happen even if Python 2 is just an apt-get away? Yes. If I'm distributing a script, I don't want to have to tell users "if you're on Debian newer than X or Ubuntu newer than Y, apt-get install python first. If you're on Fedora newer than Z...". If I couldn't rely on either 'python' or 'python3' being present, I might try to ship Python scripts with a shell wrapper that does something like this pseudocode: if (which python3): python3 my_real_script.py else: python my_real_script.py But that's ugly, and I'd be thinking things like: will the syntax I use work in plain sh, or only in bash? do all distros have bash? how similar are the shells 'sh' points to in different distros? I'm sure I could work it out, but if I need to wrap Python scripts in another language, it's a disincentive to use Python for this kind of thing. Thomas
Re: /usr/bin/python in Python 2 and 3
#!/usr/bin/python32 For bilingual scripts. On 17 Apr 2015 2:30 pm, "Geoffrey Thomas" wrote: > I've written up the proposal I made a few days ago for a /usr/bin/python > launcher that keeps the API of being Python 2, but lets scripts opt in to > running on Python 3: > > https://ldpreload.com/blog/usr-bin-python-23 > > I share the desire for /usr/bin/python to maintain its API of being Python > 2, but I also want to be able to write polyglot Python 2/3 scripts that run > everyhwere -- including on Debian machines with just Python 3. So this is a > way of "doing something else with /usr/bin/python" that's > backwards-compatible for us and all the other distros. It even happens to > be be kind of backwards-compatible for Arch, and Barry's point about > aligning the desires of the distros is a very good one. > > Let me know if you think this is a good or bad idea: I'll submit this as a > PEP as soon as we have rough consensus that this is a good idea. (We can > bikeshed the details once the idea itself is a draft PEP.) > > -- > Geoffrey Thomas > https://ldpreload.com > geo...@ldpreload.com > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/alpine.deb.2.10.1504171655000.18...@cactuar.ldpreload.com > >
Re: [Python-modules-team] Bug#782756: should not be in Section: python
On Tue, 21 Apr 2015 at 14:38 Damyan Ivanov wrote: > Its description says "static site generator". Sounds a lot like HTTP > to me, not less than ikiwiki for example. > I think you might be getting HTTP confused with HTML. Both ikiwiki and mkdocs turn files into static HTML files, but neither support serving the files using HTTP - you need to install a HTTP server to do that. I notice that ikiwiki is in the web section, however I believe that is a mistake. The web section is defined as "Web servers and their modules." however ikiwiki is not a web server or a module of a web server. Other programs for converting text files into HTML files are in the text section, e.g. docbook-utils, so I think this is the correct section. At first I looked at the "doc" section, but that seems to be about the > actual (possibly generated) documentation, not about the tools that > generate it. > Agreed.
Re: Question about private modules in /usr/share
On 21 Apr 2015, at 7:01 pm, Piotr Ożarowski wrote: > > [Potter, Tim (Cloud Services), 2015-04-21] >> binary gives an import error since /usr/share/dwarf isn’t in the PYTHONPATH: >> >> # dwarf >> Traceback (most recent call last): >> File "/usr/bin/dwarf", line 32, in >>from dwarf import log # pylint: disable=W0611 >> ImportError: No module named dwarf > > binary and module name are the same so distutils decided to copy script > to module dir: > > | running install_scripts > | copying build/scripts-2.7/dwarf -> debian/dwarf/usr/share/dwarf/dwarf > | copying build/scripts-2.7/dwarf-manage -> debian/dwarf/usr/share/dwarf > > mv debian/dwarf/usr/share/dwarf/dwarf debian/dwarf/usr/share/dwarf/run > in your install override, update symlink in debian/links and it should > work Hi Piotr. Thanks a lot! I figured it out based on your comments. Tim. smime.p7s Description: S/MIME cryptographic signature
