GNU bug report logs - #60608
keras is broken –> package bazel?

Previous Next

To reply to this bug, email your comments to 60608 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: bug-guix <at> gnu.org
Subject: keras is broken –> package bazel?
Date: Fri, 06 Jan 2023 22:16:56 +0100

We have an old version of keras.  This is now broken.  It is not
compatible with python-h5py > 2.10.  Our version of Tensorflow also
won’t work with h5py 3.

We can’t upgrade keras to anything above 2.2.5 because any later version
is built with Bazel.  We cannot build Bazel, because it needs a big pile
of jars that we haven’t packaged yet.

Tensorflow > 1.9 also requires Bazel.

We should work towards packaging Bazel.  Debian has a Bazel bootstrap
package, so I’m hopeful that it’s possible to package with some effort.

-- 
Ricardo

Message #10 received at 60608 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: 60608 <at> debbugs.gnu.org
Subject: keras is broken –> package bazel?
Date: Sat, 21 Oct 2023 17:18:38 +0200

Bazel is now available in the guix-science channel.  We may need to move
keras there too and build it with bazel.

-- 
Ricardo

Message #13 received at 60608 <at> debbugs.gnu.org (full text, mbox):

From: Sharlatan Hellseher <sharlatanus <at> gmail.com>
To: 60608 <at> debbugs.gnu.org
Cc: Ricardo Wurmus <rekado <at> elephly.net>
Subject: keras is broken –> package bazel?
Date: Wed, 18 Dec 2024 23:46:21 +0000

[Message part 1 (text/plain, inline)]

Hi,

I'm in a limbo to upgrade https://github.com/spf13/afero, which requires
go-google-golang-org-api, which relays on auto-generated code in
https://github.com/googleapis/go-genproto which was built from
https://github.com/googleapis/googleapis/ with Bazel, which we don't
have in Guix (yet?)

Any plan to have Bazel in main Guix git repository or it's not
compatibly license wise?

--
Oleg

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 60608 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Sharlatan Hellseher <sharlatanus <at> gmail.com>
Cc: 60608 <at> debbugs.gnu.org
Subject: Re: keras is broken –> package bazel?
Date: Thu, 19 Dec 2024 12:19:15 +0100

Sharlatan Hellseher <sharlatanus <at> gmail.com> writes:

> Any plan to have Bazel in main Guix git repository or it's not
> compatibly license wise?

Bazel is in guix-science, with a bazel-build-system as well.  It's
compatible when looking at just the licenses, but there are a number of
annoying wrinkles:

- Bazel itself bundles lots of binaries (Java libraries); I have made no
  serious attempt at unbundling them.  Packaging Java libraries gives me
  ulcers.

- the bazel-build-system works in ways that are really quite mismatched
  with how Guix works.  It performs a two-stage build: the first step is
  to run Bazel to download "sources" in a fixed output derivation; the
  second step (at a later time) is to unpack these hash-identified
  sources and run Bazel again without the download.

- Bazel makes it *very* hard or even impossible to replace parts of the
  build dependencies with packages from Guix.  I recently added
  python-ray to guix-science, which insists on using its own GNU Make
  (among many others).  This means that the source blob is usually
  incredibly large.

- Bazel does not care about whether something is source or binary.  The
  bazel-build-system assumes that the first step is to download sources
  only.  Bazel does not see it this way and is perfectly happy to fetch
  or build binaries at this stage.  It has happened a number of times
  that the hash of the fixed output derivation changed after an update
  of seemingly unrelated libraries, because the fixed output wasn't
  fixed after all.

I'd rather move Keras to guix-science than to contaminate Guix proper
with the abomination that is the bazel-build-system (and its relative
Bazel, which I will attempt not to call an abomination in public).

-- 
Ricardo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.