[PATCH] gnu: Add Python 3.

[PATCH] gnu: Add Python 3.

[Cyril Roelandt]

* gnu/packages/python.scm (python3): New variable.
---
 gnu/packages/python.scm | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 35d5b51..592c8a5 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -151,6 +151,18 @@ packages; exception-based error handling; and very high level dynamic
 data types.")
     (license psfl)))
 
+(define-public python3
+  (package (inherit python)
+   (version "3.3.2")
+   (source
+    (origin
+     (method url-fetch)
+     (uri (string-append "http://www.python.org/ftp/python/"
+                         version "/Python-" version ".tar.xz"))
+     (sha256
+      (base32
+       "0hsbwqjnhr85a2w252c8d3yj8d9i5sy8s6a6cfk6zqqhp3234nvl"))))))
+
 (define-public pytz
   (package
     (name "pytz")
-- 
1.8.3.1

Re: [PATCH] gnu: Add Python 3.

[Ludovic Courtès]

Cyril Roelandt <tipecaml@gmail.com> skribis:

> * gnu/packages/python.scm (python3): New variable.

[...]

> +(define-public python3
> +  (package (inherit python)
> +   (version "3.3.2")
> +   (source
> +    (origin
> +     (method url-fetch)
> +     (uri (string-append "http://www.python.org/ftp/python/"
> +                         version "/Python-" version ".tar.xz"))
> +     (sha256
> +      (base32
> +       "0hsbwqjnhr85a2w252c8d3yj8d9i5sy8s6a6cfk6zqqhp3234nvl"))))))

Nice that it works without any modifications.  Please push.  (I think
Andreas wanted to discuss the naming convention for Python packages, but
I think adding Python 3 doesn’t cause any problems.)

Ludo’.

Re: [PATCH] gnu: Add Python 3.

[Andreas Enge]

Am Mittwoch, 28. August 2013 schrieb Ludovic Courtès:
> > +(define-public python3
> 
> Nice that it works without any modifications.  Please push.  (I think
> Andreas wanted to discuss the naming convention for Python packages, but
> I think adding Python 3 doesn’t cause any problems.)

Only a little ;-)

I would rename
   (define-public python
to
   (define-public python-2

and add
   (define-public python
for python version 3 (compare libjpeg for version 9 and libjpeg-8).

Then all packages relying on python will be recompiled with the newest 
version. If this poses problems, we could modify the input to python-2.

Rationale: We would like to package the newest versions and give their 
variables the default names. If for compatibility problems, we need an 
older version, the corresponding variable should get a suffix. (While the 
NAME field of a package should be the default name in all cases.)

Andreas

Re: [PATCH] gnu: Add Python 3.

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Am Mittwoch, 28. August 2013 schrieb Ludovic Courtès:
>> > +(define-public python3
>> 
>> Nice that it works without any modifications.  Please push.  (I think
>> Andreas wanted to discuss the naming convention for Python packages, but
>> I think adding Python 3 doesn’t cause any problems.)
>
> Only a little ;-)
>
> I would rename
>    (define-public python
> to
>    (define-public python-2
>
> and add
>    (define-public python
> for python version 3 (compare libjpeg for version 9 and libjpeg-8).

What about having 3 variables: python-3, python-2, and python; ‘python’
would point to whichever is the default.

For GCC and Guile we don’t even have the version-less variable name.
Instead ‘gnu-build-system’ explicitly refers to the one we want.

Anyway, I don’t think this should block this patch.

> Then all packages relying on python will be recompiled with the newest 
> version. If this poses problems, we could modify the input to python-2.
>
> Rationale: We would like to package the newest versions and give their 
> variables the default names. If for compatibility problems, we need an 
> older version, the corresponding variable should get a suffix. (While the 
> NAME field of a package should be the default name in all cases.)

Sounds like the right approach for a start.

However, some packages will work with both versions, while others will
be 2-only or 3-only.  We’ll most likely build both variants for those
that work with both 2 and 3, for instance because there’s both a 2-only
and a 3-only package that depends on them.  Thus, eventually, there may
be a need for a procedure that rewrites a package to explicitly depend
on a given package version (similar to ‘rewritten-inputs’ in
build-system/gnu.scm).

Ludo’.

Re: [PATCH] gnu: Add Python 3.

[Andreas Enge]

On Wed, Aug 28, 2013 at 04:40:02PM +0200, Ludovic Courtès wrote:
> What about having 3 variables: python-3, python-2, and python; ‘python’
> would point to whichever is the default.

This would also be a reasonable approach. I find the 2-variable approach
more convenient, since otherwise, it would only be consistent to have
3 variables also for each python module.

Andreas

Re: [PATCH] gnu: Add Python 3.

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Aug 28, 2013 at 04:40:02PM +0200, Ludovic Courtès wrote:
>> What about having 3 variables: python-3, python-2, and python; ‘python’
>> would point to whichever is the default.
>
> This would also be a reasonable approach. I find the 2-variable approach
> more convenient, since otherwise, it would only be consistent to have
> 3 variables also for each python module.

OK.  No strong opinion on that, so either way is fine with me.

Ludo’.

Re: [PATCH] gnu: Add Python 3.

[Ludovic Courtès]

The impact of the switch from Python 2 to 3 can be seen here:

  http://hydra.gnu.org/eval/10856

That is: minus 48 packages.  :-)

Many are due to the fact that the ‘python’ executable is unavailable,
like <http://hydra.gnu.org/build/16789>.

Ludo’.

Re: [PATCH] gnu: Add Python 3.

[Andreas Enge]

On Sun, Sep 01, 2013 at 04:07:36PM +0200, Ludovic Courtès wrote:
> The impact of the switch from Python 2 to 3 can be seen here:
>   http://hydra.gnu.org/eval/10856
> That is: minus 48 packages.  :-)
> Many are due to the fact that the ‘python’ executable is unavailable,
> like <http://hydra.gnu.org/build/16789>.

Yes, so this does not really matter; we just have to decide how to support
both Python 2 and 3, and most of this should be solved.

Andreas

Re: [PATCH] gnu: Add Python 3.

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Sep 01, 2013 at 04:07:36PM +0200, Ludovic Courtès wrote:
>> The impact of the switch from Python 2 to 3 can be seen here:
>>   http://hydra.gnu.org/eval/10856
>> That is: minus 48 packages.  :-)
>> Many are due to the fact that the ‘python’ executable is unavailable,
>> like <http://hydra.gnu.org/build/16789>.
>
> Yes, so this does not really matter; we just have to decide how to support
> both Python 2 and 3, and most of this should be solved.

Agreed.

Speaking of which: in the future, we should use topic branches for such
things, to avoid disrupting the main branch.  For instance, I’ve locally
switched back to Python 2 as the default since I was otherwise unable to
use the QEMU-related things.

Actually it’s not too late: we could create a new branch off ‘master’,
and just switch back to Python 2 as the default on ‘master’.  Hydra can
be told to build the new branch in addition to ‘master’.

Thoughts?

Ludo’.

Re: [PATCH] gnu: Add Python 3.

[Andreas Enge]

On Sun, Sep 01, 2013 at 09:40:27PM +0200, Ludovic Courtès wrote:
> Speaking of which: in the future, we should use topic branches for such
> things, to avoid disrupting the main branch.  For instance, I’ve locally
> switched back to Python 2 as the default since I was otherwise unable to
> use the QEMU-related things.
> 
> Actually it’s not too late: we could create a new branch off ‘master’,
> and just switch back to Python 2 as the default on ‘master’.  Hydra can
> be told to build the new branch in addition to ‘master’.

Actually, 77c7f8f41b558bab13690c843068af8ba996e5bf switches back (while
keeping the definition of Python 3 in the variable python-3; but all
packages using python as input will get Python 2).

We could create branches; very often (like here, with changes to the python
build system pending), we might as well use core-updates directly.

Andreas

Topic branches

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Sep 01, 2013 at 09:40:27PM +0200, Ludovic Courtès wrote:
>> Speaking of which: in the future, we should use topic branches for such
>> things, to avoid disrupting the main branch.  For instance, I’ve locally
>> switched back to Python 2 as the default since I was otherwise unable to
>> use the QEMU-related things.
>> 
>> Actually it’s not too late: we could create a new branch off ‘master’,
>> and just switch back to Python 2 as the default on ‘master’.  Hydra can
>> be told to build the new branch in addition to ‘master’.
>
> Actually, 77c7f8f41b558bab13690c843068af8ba996e5bf switches back (while
> keeping the definition of Python 3 in the variable python-3; but all
> packages using python as input will get Python 2).

Ah right, thanks!

> We could create branches; very often (like here, with changes to the python
> build system pending), we might as well use core-updates directly.

Experience with Nixpkgs suggests that topic branches are better:
core-updates does rebuild-the-world changes, so you don’t want to merge
it lightly, and not too often; conversely the Python changes are
relatively isolated.

More importantly, intermingling the effects of the Python changes with
that of (say) a GCC and glibc upgrade is undesirable, as it makes it
harder to determine the cause of a problem.

Thanks,
Ludo’.

Re: Topic branches

[Andreas Enge]

On Sun, Sep 01, 2013 at 10:13:38PM +0200, Ludovic Courtès wrote:
> Experience with Nixpkgs suggests that topic branches are better:
> core-updates does rebuild-the-world changes, so you don’t want to merge
> it lightly, and not too often; conversely the Python changes are
> relatively isolated.

I just created a branch "python" and added it to hydra. Indeed, the good
thing is that one can now experiment and break everything...

Andreas