GNU Bazaar doesn't support the GNU build system

GNU Bazaar doesn't support the GNU build system

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

Hi,

I'm packaging GNU Bazaar.  Unfortunately, it doesn't support the GNU
build system.  'INSTALL' contains the following instructions:

When upgrading using setup.py, it is recommended that you first delete the
bzrlib directory from the install target.

To install bzr as a user, run

  python setup.py install --home ~ 

To install system-wide, run (as root)

  python setup.py install

I know how to replace phases.  But how can I call 'python'?

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: GNU Bazaar doesn't support the GNU build system

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

> I'm packaging GNU Bazaar.  Unfortunately, it doesn't support the GNU
> build system.

Yeah, among other things...

> 'INSTALL' contains the following instructions:
>
> When upgrading using setup.py, it is recommended that you first delete the
> bzrlib directory from the install target.
>
> To install bzr as a user, run
>
>   python setup.py install --home ~ 
>
> To install system-wide, run (as root)
>
>   python setup.py install
>
> I know how to replace phases.  But how can I call 'python'?

Like this: (system* "python" "setup.py" "install").

Ludo’.

Re: GNU Bazaar doesn't support the GNU build system

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

> Like this: (system* "python" "setup.py" "install").

Could you elaborate?

I tried several things, but none of them worked.

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: GNU Bazaar doesn't support the GNU build system

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> Like this: (system* "python" "setup.py" "install").
>
> Could you elaborate?

‘system*’ is a Guile procedure that works like system(3), except that it
executes the command directly, instead of via a shell.  So:

  (system* "python" "setup.py" "install")

runs the program ‘python’, found in $PATH, with the two arguments that
follow.

Does that clarify?

Thanks,
Ludo’.

Re: GNU Bazaar doesn't support the GNU build system

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

> Does that clarify?

I understand how 'system*' works, but I don't know where to use it. 

AFAICT, the '#:phases' keyword can't be used because it requires
'%standard-phases'.  There is also '#:builder', but I haven't found a
way to use it.

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: GNU Bazaar doesn't support the GNU build system

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

> AFAICT, the '#:phases' keyword can't be used because it requires
> '%standard-phases'.  There is also '#:builder', but I haven't found a
> way to use it.

So, #:phases is a keyword parameter recognized by ‘gnu-build-system’.
It lets you introduce, remove, or modify the normal build “phases” (see
gnu-build-system.scm).  This is useful when you just have to introduce
small changes, and when the package’s build system is similar to the GNU
build system—i.e., use something close to ./configure && make && make
install (info "(guix) Defining Packages").

In the case of Python packages, the right thing would be to define a
‘python-build-system’.  You’d add a (guix build-system python) module
that exports ‘python-build-system’; packages would use it as the value
of their ‘build-system’ field, which would mean that they get built,
installed, and tested via the ‘python setup.py install’ etc. commands.
This way, many/most Python packages would need little or no
customization once they use ‘python-build-system’.

So that’s the idea.  You could check
development/python-modules/generic/default.nix in Nixpkgs to see how
it’s done there.

I realize this is a bit more involved than “just” packaging the thing,
but it will be useful in the long run.

WDYT?

Ludo’.

Re: GNU Bazaar doesn't support the GNU build system

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

> I realize this is a bit more involved than “just” packaging the thing,
> but it will be useful in the long run.

I'm missing the big picture.  That's the main problem.  What will happen
when I run 'guix-package -i hello'?

AFAICT, '(build-system gnu-build-system)' calls 'gnu-build' with the
corresponding arguments.  But I can't find where this actually happens.

I assume that 'gnu-build' will call '%standard-phases' (from
'gnu-build-system.scm') if I don't specify any arguments.  Then
'%standard-phases' will call the functions like 'set-paths' and
'unpack'.  How does it really work?

Let's assume that I'll do the same in 'python-build-system.scm'.  Can I
reuse 'set-paths' and 'unpack'?  Should I write my own functions
instead?  How can I determine what environment variables and prefixes
should be used?

I've noticed that 'development/python-modules/generic/default.nix' uses
'easy_install'.  Should we use it?

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: GNU Bazaar doesn't support the GNU build system

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> I realize this is a bit more involved than “just” packaging the thing,
>> but it will be useful in the long run.
>
> I'm missing the big picture.  That's the main problem.  What will happen
> when I run 'guix-package -i hello'?

‘build-system’ objects are an abstraction over the underlying build
system.  A build system is basically couple of procedures: one to
perform a native build, and one to perform a cross-build (which is not
implemented yet.)

The ‘package-derivation’ procedure takes a package and return its
derivation (see the manual.)  To do that, it actually invokes the build
procedure of the package’s build system.  When it’s ‘gnu-build-system’,
the build procedure is ‘gnu-build’ from the (guix build-system gnu)
package.

In turn, this ‘gnu-build’ creates a build script that invokes the
build-side ‘gnu-build’–the one from (guix build gnu-build-system).  And
from there, you see what happens.  (See the manual about “strata”.)

If you want all the details, you can try this:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (use-modules (guix store) (guix derivations) (guix packages) (gnu packages base))
scheme@(guile-user)> (define s (open-connection))
scheme@(guile-user)> ,trace (package-derivation s guile-final)
--8<---------------cut here---------------end--------------->8---

Beware, it produces a *lot* of output.

> Let's assume that I'll do the same in 'python-build-system.scm'.  Can I
> reuse 'set-paths' and 'unpack'?  Should I write my own functions
> instead?

You would probably reuse them, yes.  So (guix build python-build-system)
would most likely #:use-module (guix build gnu-build-system), to
facilitate that.

> How can I determine what environment variables and prefixes should be
> used?

You at least need $PATH and $PYTHONPATH, perhaps $LD_LIBRARY_PATH too.

> I've noticed that 'development/python-modules/generic/default.nix' uses
> 'easy_install'.  Should we use it?

Probably, though you’d rather ask a Pythoner to check whether this is
still the recommended way.

Ludo’.