Question about (properties `((python2-variant . ,(delay XXX)))) and name resolution

Question about (properties `((python2-variant . ,(delay XXX)))) and name resolution

[Danny Milosavljevic]

Hi,

in the process of packaging ptpython I ran into the following problem:

   ;;; Failed to autoload canonical-package in (gnu packages base):
   ;;; ERROR: Unbound variable: ptpython-2

... while I did the following patch to gnu/packages/python.scm :

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index b9d61dd..5bb6b27 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -9750,3 +9750,34 @@ characters, mouse support, and auto suggestions.")
       (native-inputs
        `(("python2-setuptools" ,python2-setuptools)
          ,@(package-native-inputs base))))))
+
+(define-public ptpython
+  (package
+    (name "ptpython")
+    (version "0.34")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "ptpython" version))
+        (sha256
+          (base32
+            "1mmbiyzf0n8hm7z2a562x7w5cbl6jc0zsk6vp40q1z4cyblv1k13"))))
+    (build-system python-build-system)
+    (inputs
+      `(("python-docopt" ,python-docopt)
+        ("python-jedi" ,python-jedi)
+        ("python-prompt-toolkit" ,python-prompt-toolkit)
+        ("python-pygments" ,python-pygments)
+        ("python-setuptools" ,python-setuptools)))
+    (home-page
+      "https://github.com/jonathanslenders/ptpython")
+    (synopsis
+      "Python REPL build on top of prompt_toolkit")
+    (description
+      "Python REPL build on top of prompt_toolkit")
+    (license bsd-3)
+    (properties `((python2-variant . ,(delay ptpython-2))))
+))
+
+(define-public ptpython-2
+  (package-with-python2 ptpython))

What does it mean?

Re: Question about (properties `((python2-variant . , (delay XXX)))) and name resolution

[Leo Famulari]

On Tue, Jul 19, 2016 at 07:47:54PM +0200, Danny Milosavljevic wrote:
> +    (properties `((python2-variant . ,(delay ptpython-2))))

This 'python2-variant' system is used when the Python 2 version of a
package requires some changes beyond simply building everything with
Python 2 instead of Python 3. For example, the Python 2 variant might
require an extra dependency.

> +(define-public ptpython-2
> +  (package-with-python2 ptpython))

In this case, it looks like the Python 2 variant of the package is the
same as the Python 3 variant, aside from the Python version. So, you
should be able to drop the (properties `((python2-variant ...) line from
the python-ptpython package.

I hope that helps!

Re: Question about (properties `((python2-variant . ,(delay XXX)))) and name resolution

[Danny Milosavljevic]

Hi Leo,

On Tue, 19 Jul 2016 23:58:23 -0400
Leo Famulari <leo@famulari.name> wrote:

> In this case, it looks like the Python 2 variant of the package is the
> same as the Python 3 variant, aside from the Python version. So, you
> should be able to drop the (properties `((python2-variant ...) line from
> the python-ptpython package.

I tried that, but I still can't do

  $ guix package -i ptpython-2

because:

  guix package: error: ptpython: package not found for version 2

.

I've since settled on

 (define-public ptpython-2
  (let ((base (package-with-python2 (strip-python2-variant ptpython))))
    (package
      (inherit base)
      (name "ptpython-2"))))

... which does work. On second thought the package-with-python2 probably can't recognize the name otherwise.

Now, the ptpython executables are still called the same - so you can't install ptpython and ptpython-2 at the same time.

> I hope that helps!

Yup, thanks!

Re: Question about (properties `((python2-variant . , (delay XXX)))) and name resolution

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Leo,
>
> On Tue, 19 Jul 2016 23:58:23 -0400
> Leo Famulari <leo@famulari.name> wrote:
>
>> In this case, it looks like the Python 2 variant of the package is the
>> same as the Python 3 variant, aside from the Python version. So, you
>> should be able to drop the (properties `((python2-variant ...) line from
>> the python-ptpython package.
>
> I tried that, but I still can't do
>
>   $ guix package -i ptpython-2
>
> because:
>
>   guix package: error: ptpython: package not found for version 2

What you wrote there is the old way of asking Guix to install a
particular *version* of a package.  This has been changed to “@” some
time ago.

This means that you are asking Guix to install a package named
“ptpython” with package version “2” (not Python version 2), but no such
package exists — you only defined two variants of a package with version
0.34.

Our policy with Python *modules* is to prefix them with “python-” or
“python2-”.  When you define the Python 3 variant as “python-ptpython”
and give it the name “python-ptpython” then “package-with-python2” will
take care of renaming this to “python2-ptpython” for the Python 2
variant.

(For packages that only provide executables we usually don’t add the
prefix.)

> Now, the ptpython executables are still called the same - so you can't
> install ptpython and ptpython-2 at the same time.

Ah, an executable.  If this is not to be used as a library/module does
it even make sense to build it with different versions of Python?  If
all you care about is the executables then having a variant with only
the latest version of Python seems sufficient.  (We do the same for
snakemake, for example.)

~~ Ricardo

Re: Question about (properties `((python2-variant . , (delay XXX)))) and name resolution

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I tried that, but I still can't do
>
>   $ guix package -i ptpython-2
>
> because:
>
>   guix package: error: ptpython: package not found for version 2

[...]

>       (name "ptpython-2"))))

In the former command-line package specification syntax, which is still
supported but deprecated, “ptpython-2” was taken to mean “version 2 of
package ‘ptpython’”.  Because of this, you cannot refer to this
“ptpython-2” package from the command-line (except with -e).

The solution is to call it differently, like “ptpython2”.

Eventually (I’d say after 0.10.1 is released) we’ll remove support for
the old syntax and the problem will be gone.

HTH!
Ludo’.

Re: Question about (properties `((python2-variant . ,(delay XXX)))) and name resolution

[Danny Milosavljevic]

Hi,

On Wed, 20 Jul 2016 12:15:34 +0200
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> wrote:

> Ah, an executable.  If this is not to be used as a library/module does
> it even make sense to build it with different versions of Python?  If
> all you care about is the executables then having a variant with only
> the latest version of Python seems sufficient.

Not really. It is a Python REPL. You run it and then you write Python programs in it.

The Python version it will run the REPL in is different - so also the Python version you write Python programs for.

Installing incompatible major versions of packages alongside each other

[Danny Milosavljevic]

Hi Ludo,

> In the former command-line package specification syntax, which is still
> supported but deprecated, “ptpython-2” was taken to mean “version 2 of
> package ‘ptpython’”.  Because of this, you cannot refer to this
> “ptpython-2” package from the command-line (except with -e).
> 
> The solution is to call it differently, like “ptpython2”.

Hmm, it doesn't seem as if Guix Python itself uses that policy. Python 2.7 is called "python-2.7" (note: dash)

I'm used to semantic version numbers.

Usually, the major version is increased because something major is incompatible.

For example Python 3 changed "print" from prefix operator to function. So almost no program that uses Python 2 "print" will work in Python 3. (they also changed the default string representation and lots of other things)

Therefore, it makes sense (and is common) to install and use both Python 2 and Python 3.

For pypython, too, you'd have it be able to use a Python 2 and a Python 3 interpreter.

I think this is a general rule. However, some packages and/or developers use non-standard version numbers. Therefore it would be good to be able to override this rule as a packager.

Therefore, Gentoo packages have something called a "SLOT". It's an extra number in the package spec which specifies which slot of the base package you want to fill in the installation.

For example if you install

  dev-lang/python-3.4.3

it will install it in slot 3 [the 3 is in the package file which you can't see here; it says SLOT=3 in there] (and replace the thing in slot 3 if necessary)

and if you install

  dev-lang/python-2.7.3

it will install it in slot 2 [it says so in the package spec file] (and replace the thing in slot 2 if necessary).

If you uninstall

  dev-lang/python

it will remove both.

If you uninstall

  dev-lang/python-3.4.3

it will just remove this one.

For a completely different take, Debian just adds this kind of slot number to the package basename - as you suggest I do.

There, it would just be "python2.6" for Python 2.6 and "python3" for Python 3.

Which mechanism does Guix use? Which should it use?

The guix.texi manual seems to advocate using names like "python-2" - which I seem to have the most problems in practise with. For example right now I can't install icedtea-7: "guix package: error: icedtea: package not found for version 7"

Re: Installing incompatible major versions of packages alongside each other

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> In the former command-line package specification syntax, which is still
>> supported but deprecated, “ptpython-2” was taken to mean “version 2 of
>> package ‘ptpython’”.  Because of this, you cannot refer to this
>> “ptpython-2” package from the command-line (except with -e).
>> 
>> The solution is to call it differently, like “ptpython2”.
>
> Hmm, it doesn't seem as if Guix Python itself uses that policy. Python 2.7 is called "python-2.7" (note: dash)

The *variable* is called ‘python-2.7’, but the *name* field (which is
what matters here) has value "python".

> Which mechanism does Guix use? Which should it use?

Packages for Python 3.x are called “python-XYZ”, and packages for 2.x
are called “python2-XYZ”:

  https://www.gnu.org/software/guix/manual/html_node/Python-Modules.html

> For example right now I can't install icedtea-7: "guix package: error: icedtea: package not found for version 7"

There’s no version 7, but there are other versions available:

--8<---------------cut here---------------start------------->8---
$ guix package -A icedtea
icedtea	1.13.11	out,jdk,doc	gnu/packages/java.scm:196:2
icedtea	2.6.6	out,jdk,doc	gnu/packages/java.scm:598:4
icedtea	3.0.1	out,jdk,doc	gnu/packages/java.scm:768:4
--8<---------------cut here---------------end--------------->8---

Hope this clarifies things!

Ludo’.

Re: Installing incompatible major versions of packages alongside each other

[Leo Famulari]

On Fri, Jul 22, 2016 at 03:02:10PM +0200, Ludovic Courtès wrote:
> > For example right now I can't install icedtea-7: "guix package: error: icedtea: package not found for version 7"
> 
> There’s no version 7, but there are other versions available:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix package -A icedtea
> icedtea	1.13.11	out,jdk,doc	gnu/packages/java.scm:196:2
> icedtea	2.6.6	out,jdk,doc	gnu/packages/java.scm:598:4
> icedtea	3.0.1	out,jdk,doc	gnu/packages/java.scm:768:4
> --8<---------------cut here---------------end--------------->8---

To clarify a little more, icedtea@1 corresponds to Java 6, icedtea@2 to
Java 7, and icedtea@3 to Java 8.