unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: Python 3 binaries
Date: Sun, 01 Sep 2013 19:34:03 +0200	[thread overview]
Message-ID: <87k3j0igz8.fsf@gnu.org> (raw)
In-Reply-To: <20130901143907.GA23394@debian> (Andreas Enge's message of "Sun, 1 Sep 2013 16:39:07 +0200")

Andreas Enge <andreas@enge.fr> 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.  :-)

  reply	other threads:[~2013-09-01 17:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-31 15:30 Python 3 binaries Andreas Enge
2013-08-31 17:30 ` Cyril Roelandt
2013-08-31 18:20   ` Ludovic Courtès
2013-09-01  9:28   ` Andreas Enge
2013-09-01 10:03     ` Andreas Enge
2013-09-01 14:03     ` Ludovic Courtès
2013-09-01 14:39       ` Andreas Enge
2013-09-01 17:34         ` Ludovic Courtès [this message]
2013-09-01 17:40           ` Cyril Roelandt
2013-09-01 18:21             ` Andreas Enge
2013-09-01 17:50           ` Andreas Enge
2013-09-02  6:24           ` Brandon Invergo
2013-09-08 18:35             ` Andreas Enge
  -- strict thread matches above, loose matches on Subject: below --
2013-09-01  8:20 Brandon Invergo
2013-09-01 13:49 ` Andreas Enge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k3j0igz8.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).