Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis: With these changes in place, OK to commit. I've just pushed both patches. Please have a look. To answer your previous question, this ‘wrap’ phase serves a different (but related) purpose than the ‘native-search-paths’ thing: it ensures that the ‘bzr’ program, when run by the user, finds all its Python modules. I know. But why do we need to use 'native-search-paths' to set PYTHONPATH if we wrap all executables anyway? What is the purpose of 'native-search-paths' in this case? Not all Python packages have binaries, and when they do, they can often be used either as stand-alone binaries or as Python modules. Does that clarify? Ludo’.
Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis: If you append (package-native-search-paths python) to the list of search paths, then PYTHONPATH will automagically be defined appropriately (see http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00158.html.) If you don’t, then PYTHONPATH will be undefined, unless you explicitly define it in build/python-build-system.scm, which is not the recommended option. So just mimic the change made in the above commit for perl-build-system. OK, I've added it. Should I remove the following part? + (let* ((out (assoc-ref outputs out)) + (var `(PYTHONPATH prefix +(,(string-append out /lib/python + python-version /site-packages) +(for-each (lambda (dir) +(let ((files (list-of-files dir))) + (for-each (cut wrap-program var) +files))) + bindirs))) Or is it a different issue? Yes, see below. [...] +(define* (python-build store name source inputs + #:key + (python (@ (gnu packages python) python)) + (python-version +(string-take (package-version + (@ (gnu packages python) python)) 3)) + (tests? #t) + (configure-flags ''()) + (phases '(@ (guix build python-build-system) + %standard-phases)) + (outputs '(out)) + (search-paths '()) + (system (%current-system)) + (guile #f) + (imported-modules '((guix build python-build-system) + (guix build gnu-build-system) + (guix build utils))) + (modules '((guix build python-build-system) + (guix build gnu-build-system) + (guix build utils + Build SOURCE using PYTHON, and with INPUTS. This assumes that SOURCE +provides a 'setup.py' file as its build system. + (define python-search-paths +(append (package-native-search-paths python) +(standard-search-paths))) + + (define builder +`(begin + (use-modules ,@modules) + (python-build #:name ,name + #:source ,(if (and source (derivation-path? source)) + (derivation-path-output-path source) + source) + #:configure-flags ,configure-flags + #:system ,system + #:test-target test + #:tests? ,tests? + #:outputs %outputs + #:python-version ,python-version + #:search-paths ',(map search-path-specification-sexp + (append python-search-paths + (standard-search-paths))) Typo here. Should be: (append python-search-paths search-paths) Otherwise the ‘search-paths’ argument would not be honored. [...] +(define* (wrap #:key outputs python-version #:allow-other-keys) + (define (list-of-files dir) +(map (cut string-append dir / ) + (or (scandir dir (lambda (f) +(let ((s (stat (string-append dir / f + (eq? 'regular (stat:type s) + '( + + (define bindirs +(append-map (match-lambda + ((_ . dir) + (list (string-append dir /bin) +(string-append dir /sbin +outputs)) + + (let* ((out (assoc-ref outputs out)) + (var `(PYTHONPATH prefix +(,(string-append out /lib/python + python-version /site-packages) We also need to account for extra Python modules the package depends on: (let* (... (var `(PYTHONPATH prefix ,(cons (string-append out /lib/python python-version /site-packages) (search-path-as-string-list (or (getenv PYTHONPATH) ) ...) To answer your previous question, this ‘wrap’ phase serves a different (but related) purpose than the ‘native-search-paths’ thing: it ensures that the ‘bzr’ program, when run by the user, finds all its Python modules. [...] +(define-public bazaar + (package +(name bazaar) +(version 2.5.1) +(source + (origin + (method url-fetch) + (uri (string-append https://launchpad.net/bzr/2.5/; version + /+download/bzr- version .tar.gz)) + (sha256 + (base32 +
Re: 'python-build-system'
With these changes in place, OK to commit. I've just pushed both patches. Please have a look. To answer your previous question, this ‘wrap’ phase serves a different (but related) purpose than the ‘native-search-paths’ thing: it ensures that the ‘bzr’ program, when run by the user, finds all its Python modules. I know. But why do we need to use 'native-search-paths' to set PYTHONPATH if we wrap all executables anyway? What is the purpose of 'native-search-paths' in this case? pgp0dtUQNo6x9.pgp Description: PGP signature
Re: 'python-build-system'
If you append (package-native-search-paths python) to the list of search paths, then PYTHONPATH will automagically be defined appropriately (see http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00158.html.) If you don’t, then PYTHONPATH will be undefined, unless you explicitly define it in build/python-build-system.scm, which is not the recommended option. So just mimic the change made in the above commit for perl-build-system. OK, I've added it. Should I remove the following part? + (let* ((out (assoc-ref outputs out)) + (var `(PYTHONPATH prefix +(,(string-append out /lib/python + python-version /site-packages) +(for-each (lambda (dir) +(let ((files (list-of-files dir))) + (for-each (cut wrap-program var) +files))) + bindirs))) Or is it a different issue? If both do the same thing, the 'package-native-search-paths' approach feels more verbose. Because one should specify it in recipes. Am I mistaken? Can I push both patches to 'master'? From f81f98e05a7b3a08afbebd1e756dff37b76847f1 Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov nik...@karetnikov.org Date: Wed, 8 May 2013 00:44:12 + Subject: [PATCH] Add 'python-build-system'. * guix/build-system/python.scm, guix/build/python-build-system.scm: New files. * Makefile.am (MODULES): Add them. --- Makefile.am|2 + guix/build-system/python.scm | 115 guix/build/python-build-system.scm | 89 3 files changed, 206 insertions(+), 0 deletions(-) create mode 100644 guix/build-system/python.scm create mode 100644 guix/build/python-build-system.scm diff --git a/Makefile.am b/Makefile.am index 0f325c8..15cbde8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -46,6 +46,7 @@ MODULES = \ guix/build-system/cmake.scm \ guix/build-system/gnu.scm \ guix/build-system/perl.scm \ + guix/build-system/python.scm \ guix/build-system/trivial.scm \ guix/ftp-client.scm\ guix/web.scm \ @@ -56,6 +57,7 @@ MODULES = \ guix/build/cmake-build-system.scm \ guix/build/gnu-build-system.scm \ guix/build/perl-build-system.scm \ + guix/build/python-build-system.scm \ guix/build/utils.scm\ guix/build/union.scm\ guix/packages.scm\ diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm new file mode 100644 index 000..f90d1a5 --- /dev/null +++ b/guix/build-system/python.scm @@ -0,0 +1,115 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2013 Ludovic Courtès l...@gnu.org +;;; Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix build-system python) + #:use-module (guix store) + #:use-module (guix utils) + #:use-module (guix packages) + #:use-module (guix derivations) + #:use-module (guix build-system) + #:use-module (guix build-system gnu) + #:use-module (ice-9 match) + #:export (python-build +python-build-system)) + +;; Commentary: +;; +;; Standard build procedure for Python packages using 'setup.py'. This is +;; implemented as an extension of 'gnu-build-system'. +;; +;; Code: + +(define* (python-build store name source inputs + #:key + (python (@ (gnu packages python) python)) + (python-version +(string-take (package-version + (@ (gnu packages python) python)) 3)) + (tests? #t) + (configure-flags ''()) + (phases '(@ (guix build python-build-system) + %standard-phases)) + (outputs '(out)) + (search-paths '()) + (system (%current-system)) + (guile #f) + (imported-modules '((guix build python-build-system) + (guix build gnu-build-system) + (guix build utils))) + (modules '((guix build python-build-system) +
Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis: Well, I have always used python setup.py subcommand, but there might be a few differences between these build systems: http://wokslog.wordpress.com/2011/06/04/distutils-diff/ So, can I use 'python-build-system', then? IMO, yes. Ludo’.
Re: 'python-build-system'
Well, I have always used python setup.py subcommand, but there might be a few differences between these build systems: http://wokslog.wordpress.com/2011/06/04/distutils-diff/ So, can I use 'python-build-system', then? pgpmlyvgOeSMn.pgp Description: PGP signature
Re: 'python-build-system'
l...@gnu.org (Ludovic Courtès) skribis: Nikita Karetnikov nik...@karetnikov.org skribis: --- a/guix/build/utils.scm +++ b/guix/build/utils.scm @@ -680,8 +680,8 @@ contents: This is useful for scripts that expect particular programs to be in $PATH, for programs that expect particular shared libraries to be in $LD_LIBRARY_PATH, or modules in $GUILE_LOAD_PATH, etc. - (let ((prog-real (string-append . prog -real)) -(prog-tmp (string-append . prog -tmp))) + (let ((prog-real (string-append (dirname prog) /. (basename prog) -real)) +(prog-tmp (string-append (dirname prog) /. (basename prog) -tmp))) OK. (define (export-variable lst) ;; Return a string that exports an environment variable. (match lst @@ -709,11 +709,11 @@ modules in $GUILE_LOAD_PATH, etc. (with-output-to-file prog-tmp (lambda () (format #t -#!~a~%~a~%exec ~a~% +#!~a~%~a~%exec ~a $@~% Make it #!~a~%~a~%exec ~a \$@\~%. (which bash) (string-join (map export-variable vars) \n) -(canonicalize-path prog-real +prog-real))) Keep ‘canonicalize-path’ here, it doesn’t hurt. I’ve applied your patch with these modifications. Thanks, Ludo’.
Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis: Yes, definitely. But that’s not a problem: these scripts are most likely unused during the build process and afterward. So, should I package it (without replacing shells)? No, no need for zsh here, AFAICS. * guix/build/utils.scm (wrap-program): Assume that 'prog' is an absolute filename. Adjust 'prog-real' and 'prog-tmp' accordingly. Also, change 'prog-tmp' to honor command line arguments. What was wrong with the previous approach? I don’t like the “assume it’s an absolute file name” bit, because we don’t know whether the assumption holds. Well, have a look at this snippet: + (for-each (cut wrap-program var) +files))) Each 'file' here will have an absolute filename. I failed to make it work with the previous version. Can you clarify what didn’t work exactly? It’s not clear to me. You need double quotes around $@. Why should I add them? So that argument expansion does not incur further splitting, in case of arguments containing white space (info (bash) Special Parameters). You also need to keep (package-native-search-paths python). See commit 35ac56b6, which fixed that for Perl co. Could you elaborate? Why is it needed? Is it necessary to add 'python-search-paths'? If you append (package-native-search-paths python) to the list of search paths, then PYTHONPATH will automagically be defined appropriately (see http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00158.html.) If you don’t, then PYTHONPATH will be undefined, unless you explicitly define it in build/python-build-system.scm, which is not the recommended option. So just mimic the change made in the above commit for perl-build-system. HTH, Ludo’.
Re: 'python-build-system'
Cyril Roelandt tipec...@gmail.com skribis: On 04/28/2013 03:55 AM, Nikita Karetnikov wrote: What’s the status of this? It would be great to have it in time for 0.2. OK, I'll try to finalize it today. Should we really call this python-build-system ? I think there are a few different build systems for Python, even though they are all forks of one another (distutils, setuptools, distutils2, distribute, and maybe others). But how do they differ from the user’s POV? My understanding was that distutils* and setuptools provide the ‘python setup.py’ interface, with the same arguments and everything, no? I'm not sure that Python chose one of these as the official build system. Maybe we should use names such as python-setuptools-build-system. WDYT ? If the command-line interface is different, then yes. But if they have the same command-line interface, then it doesn’t make sense to distinguish among them, I think. Thanks, Ludo’.
Re: 'python-build-system'
Oh, I see now! Nikita Karetnikov nik...@karetnikov.org skribis: --- a/guix/build/utils.scm +++ b/guix/build/utils.scm @@ -680,8 +680,8 @@ contents: This is useful for scripts that expect particular programs to be in $PATH, for programs that expect particular shared libraries to be in $LD_LIBRARY_PATH, or modules in $GUILE_LOAD_PATH, etc. - (let ((prog-real (string-append . prog -real)) -(prog-tmp (string-append . prog -tmp))) + (let ((prog-real (string-append (dirname prog) /. (basename prog) -real)) +(prog-tmp (string-append (dirname prog) /. (basename prog) -tmp))) OK. (define (export-variable lst) ;; Return a string that exports an environment variable. (match lst @@ -709,11 +709,11 @@ modules in $GUILE_LOAD_PATH, etc. (with-output-to-file prog-tmp (lambda () (format #t -#!~a~%~a~%exec ~a~% +#!~a~%~a~%exec ~a $@~% Make it #!~a~%~a~%exec ~a \$@\~%. (which bash) (string-join (map export-variable vars) \n) -(canonicalize-path prog-real +prog-real))) Keep ‘canonicalize-path’ here, it doesn’t hurt. I think this can go in (in ‘core-updates’) with these two small changes. And then we can merge ‘core-updates’. Thanks! Ludo’.
Re: 'python-build-system'
'bazaar.scm' is for testing. The following warnings appear during the installation: GNU gettext msgfmt utility not found! patch-shebang: ./tools/packaging/lp-upload-release: warning: no binary for interpreter `zsh' found in $PATH patch-shebang: ./tools/weavemerge.sh: warning: no binary for interpreter `zsh' found in $PATH Can we replace 'zsh' with 'bash'? I guess there may be some compatibility problems. Should we package 'zsh' instead? I haven't checked, but it seems there are two tarballs: the first one contains sources and the second contains docs. Is there a way to specify both in a single recipe? Also, I should mention that I don't understand some parts of the build system. I'm not sure how to check them. Is there a Scheme level 'strace'-like tool? If not, I'll send more specific questions later. From aa73cd5d8e5e48d24460c9d6bcebfc92b3311d4c Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov nik...@karetnikov.org Date: Sun, 28 Apr 2013 16:08:23 + Subject: [PATCH] utils: Adjust 'wrap-program'. * guix/build/utils.scm (wrap-program): Assume that 'prog' is an absolute filename. Adjust 'prog-real' and 'prog-tmp' accordingly. Also, change 'prog-tmp' to honor command line arguments. --- guix/build/utils.scm |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/guix/build/utils.scm b/guix/build/utils.scm index 356dd46..fe6978b 100644 --- a/guix/build/utils.scm +++ b/guix/build/utils.scm @@ -680,8 +680,8 @@ contents: This is useful for scripts that expect particular programs to be in $PATH, for programs that expect particular shared libraries to be in $LD_LIBRARY_PATH, or modules in $GUILE_LOAD_PATH, etc. - (let ((prog-real (string-append . prog -real)) -(prog-tmp (string-append . prog -tmp))) + (let ((prog-real (string-append (dirname prog) /. (basename prog) -real)) +(prog-tmp (string-append (dirname prog) /. (basename prog) -tmp))) (define (export-variable lst) ;; Return a string that exports an environment variable. (match lst @@ -709,11 +709,11 @@ modules in $GUILE_LOAD_PATH, etc. (with-output-to-file prog-tmp (lambda () (format #t -#!~a~%~a~%exec ~a~% +#!~a~%~a~%exec ~a $@~% (which bash) (string-join (map export-variable vars) \n) -(canonicalize-path prog-real +prog-real))) (chmod prog-tmp #o755) (rename-file prog-tmp prog))) -- 1.7.5.4 From e217b27883223f4c6adc39c4ed3c1af6d1ddf4af Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov nik...@karetnikov.org Date: Sun, 28 Apr 2013 12:55:27 + Subject: [PATCH] Add 'python-build-system'. * guix/build-system/python.scm, guix/build/python-build-system.scm: New files. * Makefile.am (MODULES): Add them. --- Makefile.am|2 + guix/build-system/python.scm | 111 guix/build/python-build-system.scm | 89 + 3 files changed, 202 insertions(+), 0 deletions(-) create mode 100644 guix/build-system/python.scm create mode 100644 guix/build/python-build-system.scm diff --git a/Makefile.am b/Makefile.am index 847d850..7172a90 100644 --- a/Makefile.am +++ b/Makefile.am @@ -46,6 +46,7 @@ MODULES = \ guix/build-system/cmake.scm \ guix/build-system/gnu.scm \ guix/build-system/perl.scm \ + guix/build-system/python.scm \ guix/build-system/trivial.scm \ guix/ftp-client.scm\ guix/web.scm \ @@ -56,6 +57,7 @@ MODULES = \ guix/build/cmake-build-system.scm \ guix/build/gnu-build-system.scm \ guix/build/perl-build-system.scm \ + guix/build/python-build-system.scm \ guix/build/utils.scm\ guix/build/union.scm\ guix/packages.scm\ diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm new file mode 100644 index 000..55d752a --- /dev/null +++ b/guix/build-system/python.scm @@ -0,0 +1,111 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2013 Ludovic Courtès l...@gnu.org +;;; Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix build-system python) + #:use-module (guix store) + #:use-module
Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis: 'bazaar.scm' is for testing. The following warnings appear during the installation: GNU gettext msgfmt utility not found! Just add gettext as an input. patch-shebang: ./tools/packaging/lp-upload-release: warning: no binary for interpreter `zsh' found in $PATH patch-shebang: ./tools/weavemerge.sh: warning: no binary for interpreter `zsh' found in $PATH Can we replace 'zsh' with 'bash'? I guess there may be some compatibility problems. Yes, definitely. But that’s not a problem: these scripts are most likely unused during the build process and afterward. Also, I should mention that I don't understand some parts of the build system. I'm not sure how to check them. Is there a Scheme level 'strace'-like tool? If not, I'll send more specific questions later. Well, there’s ‘pk’ and ‘format’, to add debugging statements here and there. There’s also the debugger. From aa73cd5d8e5e48d24460c9d6bcebfc92b3311d4c Mon Sep 17 00:00:00 2001 From: Nikita Karetnikov nik...@karetnikov.org Date: Sun, 28 Apr 2013 16:08:23 + Subject: [PATCH] utils: Adjust 'wrap-program'. * guix/build/utils.scm (wrap-program): Assume that 'prog' is an absolute filename. Adjust 'prog-real' and 'prog-tmp' accordingly. Also, change 'prog-tmp' to honor command line arguments. What was wrong with the previous approach? I don’t like the “assume it’s an absolute file name” bit, because we don’t know whether the assumption holds. guix/build/utils.scm |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/guix/build/utils.scm b/guix/build/utils.scm index 356dd46..fe6978b 100644 --- a/guix/build/utils.scm +++ b/guix/build/utils.scm @@ -680,8 +680,8 @@ contents: This is useful for scripts that expect particular programs to be in $PATH, for programs that expect particular shared libraries to be in $LD_LIBRARY_PATH, or modules in $GUILE_LOAD_PATH, etc. - (let ((prog-real (string-append . prog -real)) -(prog-tmp (string-append . prog -tmp))) + (let ((prog-real (string-append (dirname prog) /. (basename prog) -real)) +(prog-tmp (string-append (dirname prog) /. (basename prog) -tmp))) (define (export-variable lst) ;; Return a string that exports an environment variable. (match lst @@ -709,11 +709,11 @@ modules in $GUILE_LOAD_PATH, etc. (with-output-to-file prog-tmp (lambda () (format #t -#!~a~%~a~%exec ~a~% +#!~a~%~a~%exec ~a $@~% Oops, indeed. You need double quotes around $@. (which bash) (string-join (map export-variable vars) \n) -(canonicalize-path prog-real +prog-real))) (chmod prog-tmp #o755) (rename-file prog-tmp prog))) + (define builder +`(begin + (use-modules ,@modules) + (python-build #:name ,name + #:source ,(if (and source (derivation-path? source)) + (derivation-path-output-path source) + source) + #:configure-flags ,configure-flags + #:system ,system + #:test-target test + #:tests? ,tests? + #:outputs %outputs + #:python-version ,python-version + #:search-paths ',(map search-path-specification-sexp + (append search-paths + (standard-search-paths))) You also need to keep (package-native-search-paths python). See commit 35ac56b6, which fixed that for Perl co. Otherwise looks good. Thanks! Ludo’.
Re: 'python-build-system'
Yes, definitely. But that’s not a problem: these scripts are most likely unused during the build process and afterward. So, should I package it (without replacing shells)? * guix/build/utils.scm (wrap-program): Assume that 'prog' is an absolute filename. Adjust 'prog-real' and 'prog-tmp' accordingly. Also, change 'prog-tmp' to honor command line arguments. What was wrong with the previous approach? I don’t like the “assume it’s an absolute file name” bit, because we don’t know whether the assumption holds. Well, have a look at this snippet: + (for-each (cut wrap-program var) +files))) Each 'file' here will have an absolute filename. I failed to make it work with the previous version. Should I change the commit message? You need double quotes around $@. Why should I add them? You also need to keep (package-native-search-paths python). See commit 35ac56b6, which fixed that for Perl co. Could you elaborate? Why is it needed? Is it necessary to add 'python-search-paths'? pgpHbFcpJdXQB.pgp Description: PGP signature
Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis:
The main problem is that 'set-path-environment-variable' doesn't seem
to work.
Could you be more precise? :-) At the beginning of the build log, there
should be a line saying ‘PYTHONPATH set to ...’. What does this say?
I used Bazaar (don't forget to apply this patch [1] first) to test the
build system:
So you did build it successfully, right?
# /nix/var/nix/profiles/per-user/root/guix-profile/bin/bzr --help
bzr: warning: unsupported locale setting
bzr could not set the application locale.
Although this should be no problem for bzr itself, it might
cause problems with some plugins. To investigate the issue,
look at the output of the locale(1p) tool.
bzr: ERROR: Couldn't import bzrlib and dependencies.
Please check the directory containing bzrlib is on your PYTHONPATH.
The ‘bzr’ binary should be wrapped (with ‘wrap-program’) in a wrapper
that sets PYTHONPATH to point to $out/lib/python2.7/site-packages (which
you did manually.)
I think it’s something that should be done automatically by
‘python-build-system’. That is, after the ‘install’ phase, it should
traverse all the binaries in $out/{bin,sbin} and wrap them. The
wrappers should set PYTHONPATH to
$out/lib/python2.7/site-packages:$PYTHONPATH, where $PYTHONPATH is the
build-time $PYTHONPATH.
More questions:
1. How can I get the version of Python in 'python-build-system.scm'?
(I hardcoded it for now.)
In python.scm (the host-side module), you can do
(package-version python)
You could pass that to the builder, say via #:python-version, so
python-build-system.scm can use it.
But note that in general the interesting bit is “2.7”, not “2.7.1”.
2. Can I remove the 'strip' phase? Is it useful for Python packages?
There could be .so files, so you can leave it (it doesn’t hurt anyway.)
There is a problem with Bazaar too. Actually, it's a 'gnutls' problem.
I packaged Bazaar 2.3.1 because I can't get the hashes of the latest
versions. For example:
# ./pre-inst-env guix download
https://launchpad.net/bzr/2.5/2.5.1/+download/bzr-2.5.1.tar.gz
[...]
ERROR: missing interface for module (gnutls)
That’s because GnuTLS is not available on your system. You must install
it if you want to be able to use ‘guix download’ with https.
Fortunately, you just have to type ‘guix package -i gnutls’. :-)
(define* (python-build #:key inputs (phases %standard-phases)
#:allow-other-keys #:rest args)
Build the given Python package, applying all of PHASES in order.
(set-path-environment-variable PYTHONPATH
'(lib/python2.7/site-packages)
(match inputs
(((_ . location) ...)
location)))
(apply gnu:gnu-build #:inputs inputs #:phases phases args))
In ‘core-updates’ there’s a better mechanism for search paths. You can
do the above in ‘master’, but for ‘core-updates’ please see in commit
a18eda2747fa2eb962e3288066d2b1a679589ed3 how ‘perl-build-system’ handles
its search path.
Other than that, looks great!
Thanks,
Ludo’.
