[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python 3 binaries
From: |
Ludovic Courtès |
Subject: |
Re: Python 3 binaries |
Date: |
Sun, 01 Sep 2013 19:34:03 +0200 |
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
Andreas Enge <address@hidden> skribis:
> On Sun, Sep 01, 2013 at 04:03:47PM +0200, Ludovic Courtès wrote:
>> Ah, so packages that work with Python 3 expect a ‘python’ (and not
>> ‘python3’) executable?
>
> Apparently so. And anyway, packages that work with both versions usually
> start their scripts with #!/usr/bin/python.
OK.
>> Then that’s a different story (I thought ‘python3’ was the official name
>> for the binary.)
>>
>> I’d rather not have specific things like that in ‘patch-shebangs’. So,
>> what we could do is:
>> • Leave ‘python-3’ as is, without the symlink.
>> • Add a ‘python-3-wrapper’ package that just contains ‘bin/python’
>> pointing to ‘…/bin/python3’ (using ‘trivial-build-system’.)
>> • When building Python 3 packages, we’d use the wrapper, not the real
>> one; however, users would install the real one in their environment.
>
> This would be a possibility.
>
> Personally, I find the solution rewriting the shebangs cleaner, but this
> is more a matter of taste than anything.
>
> The wrapper would require the user to install both python-3 and the wrapper
> (or contain python-3 as a propagated input), so that the user has all files
> in the python-3 package. This is slightly ugly.
Users would typically only need to install the wrapper; that’s enough
since it holds a reference to the real Python.
However, my understanding from what Cyril and Brandon said is that users
may prefer to have it called ‘python3’ by default, so they can install
both Python 2 and Python 3 in parallel. Furthermore, they can choose to
have (say) an alias python=python3 if that’s what they want.
Based on that, I thought the wrapper would be mostly for internal
consumption.
Did I get it right?
> The solution with the wrapper has the advantage that users who want only
> Python 3 and not Python 2 would then get a binary named "python" pointing
> to version 3, useful also for their own code. But somewhere it would have
> to be documented that they then have to install python-3-wrapper and not just
> python or python-3.
>
> But the naming is not very clear; why do I need to install python-wrapper
> if I just want the latest version of Python?
> How about calling the package python-default and having it contain python-3
> as a propagated input? We could even have a version 2 of this package, which
> would be empty with only python-2 as a propagated input. Then the user could:
>
> - install python-default = python-default-3 and get only Python 3,
> with binaries "python" and "pydoc" pointing to "python3" and "pydoc3",
> respectively;
> - install python-default-2 and get only Python 2.
> - install python-2 and python = python-3 to get both of them, with
> "python" pointing to Python 2.
>
> What do you think?
My understanding was that users (really: Python developers) would expect
to get a ‘python3’ binary when they install the latest, and a ‘python’
binary otherwise.
Then that means we don’t really have to worry, and just document that
the python-3.x package is an unmodified upstream package, with its
binary is called ‘python3’.
WDYT?
Ludo’, who’d really appreciate feedback from the Python-savvy. :-)