| Message ID | cover.1658595756.git.guix@ikherbers.com |
|---|---|
| Headers | show |
| Series | Add sagemath. | expand |
Hello! vicvbcun <guix@ikherbers.com> skribis: > This series adds SageMath. Everything compiles just fine and even the > Jupyter notebook interface works, but there is still much work to do. So > far, I have only added the minimal set of inputs required for the build > to succeed. Tests and documentations are still missing. This looks great already! To make sure things don’t stall, we could apply the patch series piecemeal, starting with the dependencies that you think are ready, and leaving more time to polish the ‘sagemath’ package. WDYT? Regarding SageMath, my understanding is that it bundles lots of things. In Guix, we’d like to make sure we do not use the bundled packages, unless we practically can’t avoid it. To do that, the best option is to remove “third-party” (or similar) directories right in the ‘snippet’ of the ‘sagemath’ package. Could you give that a try? Then, as you note, we’d rather run tests to make sure the package works as intended. Cc’ing Andreas, who I think is quite familiar with Sage. Ludo’.
Hello, On 2022-08-01T11:24:31+0200, Ludovic Courtès wrote: > > This series adds SageMath. Everything compiles just fine and even the > > Jupyter notebook interface works, but there is still much work to do. So > > far, I have only added the minimal set of inputs required for the build > > to succeed. Tests and documentations are still missing. > > This looks great already! To make sure things don’t stall, we could > apply the patch series piecemeal, starting with the dependencies that > you think are ready, and leaving more time to polish the ‘sagemath’ > package. > > WDYT? Sounds like a good idea. The updates all seem fine to me (except gap) and other than perhaps a better description for python-memory-allocator I don't think there is much left to do for the other ones. As for gap, I took another stab at it and it now builds reproducibly for me. I also removed all the trailing #t's and changed the phases to use a gexp. By the way, the gap definition contains a snippet that deletes many gap packages over concerns due to missing explicit licenses. However in a cursory look at the tarball, I can see many LICENSE/COPYING files so that may have changed. > Regarding SageMath, my understanding is that it bundles lots of things. > In Guix, we’d like to make sure we do not use the bundled packages, > unless we practically can’t avoid it. To do that, the best option is to > remove “third-party” (or similar) directories right in the ‘snippet’ of > the ‘sagemath’ package. Could you give that a try? If I understand the Sage build system correctly, missing dependencies are automatically retrieved and build only when using the provided Makefile. As is, the package definition builds and installs only the python library part using setup.py. Thus a missing dependency probably leads to a runtime error, though I haven't checked this. > Then, as you note, we’d rather run tests to make sure the package works > as intended. I will try to see if I can get tests to work, though probably as separate "package" like nixpkgs does[0], to avoid rebuilding sagemath so often :). As for sagemath itself, I will have a look at what exactly we need in bin/. [0]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/math/sage/sage-tests.nix
On 2022-07-23T21:59:07+0200, vicvbcun wrote: > Everything compiles just fine and even the Jupyter notebook interface > works, [...] Well, I spoke to soon. As it turns out, the `sage' command I invoked to test things a bit wound up using the sage installed by pacman, so no wonder it worked perfectly. Nonetheless, I got some things working in a guix shell container (so hopefully this wont happen again) with the help of wrap-program and a few more dependencies. I will try to post something that actually works a bit soon.
Hello, Am Mon, Aug 01, 2022 at 11:24:31AM +0200 schrieb Ludovic Courtès: > > This series adds SageMath. Everything compiles just fine and even the > > Jupyter notebook interface works, but there is still much work to do. So > > far, I have only added the minimal set of inputs required for the build > > to succeed. Tests and documentations are still missing. > This looks great already! To make sure things don’t stall, we could > apply the patch series piecemeal, starting with the dependencies that > you think are ready, and leaving more time to polish the ‘sagemath’ > package. thanks for letting me know, I will start by having a look at the patches doing version updates. Concerning sagemath itself, below is my very old version of an attempt at packaging the library. Some things look reassuringly similar, my handling of the number of cores is less nice, but I do delete the bundled packages. Maybe you could copy useful parts into your recipe? As for tests, indeed we should drop them for the time being until we have a working sage package. Thanks for these efforts! Andreas (define-public sage (package (name "sage") (version "8.7") (source (origin (method url-fetch) (uri (string-append "ftp://ftp.fu-berlin.de/unix/misc/sage/src/sage-" version ".tar.gz")) (sha256 (base32 "04l7i29vvxbd276z7hq6lj00ij42iy05pj7x765f0wswjiz0jlax")) (modules '((guix build utils))) (snippet '(begin (delete-file-recursively "upstream") (delete-file-recursively ".git") #t)))) (build-system python-build-system) (native-inputs `(("cython" ,python-cython) ("pkg-config" ,pkg-config) ("python-cysignals" ,python-cysignals) ("python-pkgconfig" ,python-pkgconfig) ("python-jinja2" ,python-jinja2))) (inputs `(("arb" ,arb) ("boost" ,boost) ("brial" ,brial) ("cliquer" ,cliquer) ("ecl" ,ecl) ("eclib" ,eclib) ("gmp-ecm" ,gmp-ecm) ("edge-addition-planarity-suite" ,edge-addition-planarity-suite) ("fflas-ffpack" ,fflas-ffpack-2.3.2) ("flint" ,flint) ("gap" ,gap) ("gd" ,gd) ("gf2x" ,gf2x) ("givaro" ,givaro-4.0.4) ("glpk" ,glpk) ("gmp" ,gmp) ("gsl" ,gsl) ("iml" ,iml) ("lcalc" ,lcalc) ("libbraiding" ,libbraiding) ("libgc" ,libgc) ("libhomfly" ,libhomfly) ("linbox" ,linbox-1.5.2) ("lrcalc" ,lrcalc) ("m4ri" ,m4ri) ("m4rie" ,m4rie) ("mpc" ,mpc) ("mpfr" ,mpfi) ("ntl" ,ntl) ("pari-gp" ,pari-gp) ("ppl" ,ppl) ("pynac" ,pynac) ("python-cypari2" ,python-cypari2) ("python-gmpy2" ,python-gmpy2) ("python-numpy" ,python-numpy) ("python-six" ,python-six) ("ratpoints" ,ratpoints) ("readline" ,readline) ("rw" ,rw) ("singular" ,singular) ("symmetrica" ,symmetrica) ("zlib" ,zlib) ("zn-poly" ,zn-poly))) (arguments `(#:tests? #f ; a test since this phase fails with an error in setup.py #:use-setuptools? #f ; otherwise setup.py complains about ; --single-version-externally-managed #:phases (modify-phases %standard-phases (add-before 'build 'setup (lambda _ (setenv "SAGE_ROOT" (getcwd)) (setenv "SAGE_LOCAL" (getcwd)) (setenv "SAGE_SHARE" (string-append (getcwd) "/share")) (setenv "PATH" (string-append (getcwd) "/build/bin:" (getcwd) "/src/bin:" (getenv "PATH"))) (setenv "SAGE_NUM_THREADS" "32") ; arbitrary number, 32 cores ; on bayfront (mkdir-p "var/lib/sage/installed") (mkdir-p (string-append (getcwd) "/share/sage/ext/notebook-ipython")) (chdir "src") #t)) (add-after 'install 'save-space ;; The Nix package deletes a directory with over 100MB, which ;; apparently is not needed. Let us do the same. (lambda* (#:key inputs outputs #:allow-other-keys) (let* ((out (assoc-ref outputs "out")) (python (assoc-ref inputs "python")) (python-version ((@@ (guix build python-build-system) get-python-version) python)) (site (string-append out "/lib/python" python-version "/site-packages")) (directory (string-append site "/sage/cython_debug"))) (delete-file-recursively directory)) #t))))) (synopsis "SageMath computer algebra system") (description "SageMath is a mathematics software built on top of many existing packages such as NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and others. Their combined power may be accessed through a common, Python-based language or directly via interfaces or wrappers.") ;; documentation under cc-by-sa3.0, bundled packages under various ;; other licenses, see COPYING.txt in the distribution (license license:gpl3) (home-page "https://www.sagemath.org/")))
Hello, On 2022-08-08T16:40:37+0200, Andreas Enge wrote: > Hello, > > Am Mon, Aug 01, 2022 at 11:24:31AM +0200 schrieb Ludovic Courtès: > > > This series adds SageMath. Everything compiles just fine and even the > > > Jupyter notebook interface works, but there is still much work to do. So > > > far, I have only added the minimal set of inputs required for the build > > > to succeed. Tests and documentations are still missing. > > This looks great already! To make sure things don’t stall, we could > > apply the patch series piecemeal, starting with the dependencies that > > you think are ready, and leaving more time to polish the ‘sagemath’ > > package. > > thanks for letting me know, I will start by having a look at the patches > doing version updates. Great! But note that I just sent an updated series with minor touch ups :). > Concerning sagemath itself, below is my very old version of an attempt at > packaging the library. Some things look reassuringly similar, my handling > of the number of cores is less nice, but I do delete the bundled packages. The `upstream' directory only seems to exist in the published tarball. So this should be no problem if we build from git. > Maybe you could copy useful parts into your recipe? I'll take a look! > As for tests, indeed we should drop them for the time being until we have > a working sage package. Too late (for the most part) :).
Hello, Am Mon, Aug 08, 2022 at 06:20:22PM +0200 schrieb guix@ikherbers.com: > Great! But note that I just sent an updated series with minor touch ups :). thanks for the update! I just pushed an update of maxima (and wxmaxima), but without your addition of ecl. Is there a good reason for this? In any case, this should be done in a separate commit, since it is not required for the update. For the record, I also tried to compile with gcl, but this still failed. > > Concerning sagemath itself, below is my very old version of an attempt at > > packaging the library. Some things look reassuringly similar, my handling > > of the number of cores is less nice, but I do delete the bundled packages. > The `upstream' directory only seems to exist in the published tarball. > So this should be no problem if we build from git. Ah, interesting. Which one should we do? I personally tend to prefer tarballs (as the official distribution mechanism of the project). Recently there has been a preference in the Guix project for git repositories when autotools are involved, as they make it possible to recreate the configure scripts from their source. But since this is not the case here, the argument does not hold. Andreas
On Tue Aug 9, 2022 at 11:47 AM BST, Andreas Enge wrote: > Ah, interesting. Which one should we do? I personally tend to prefer tarballs > (as the official distribution mechanism of the project). Recently there has > been a preference in the Guix project for git repositories when autotools > are involved, as they make it possible to recreate the configure scripts > from their source. But since this is not the case here, the argument does > not hold. I think it does sometimes hold even for projects that don't use autotools, especially older ones: they sometimes work under the assumption that users do not generally care about generated files in their release source, but don't want to put generated files in their development repository. This, of course, is why the autotools generated files problem exists in the first place; autoconf was, after all, designed so that users didn't have to have it installed to build a package, in a world where compiling from release tarballs was the usual way to get new software. -- (
I pushed your patch updating cddlib with a small change to include the version number in the docdir, so that it coincides with the place where the GNU build system stores the COPYING file. Thanks, Andreas
On 09-08-2022 12:47, Andreas Enge wrote: > [...] Recently there has > been a preference in the Guix project for git repositories when autotools > are involved, as they make it possible to recreate the configure scripts > from their source. But since this is not the case here, the argument does > not hold. I am not aware of such a preference, do you have a source? Switching to git repositories in one method to build from source, but there exist other methods too that keep the official distribution method, e.g. (for-each delete-file '("configure" ...)) in a snippet. It's a method to a goal, but not a goal on itself as far as I'm aware. Greetings, Maxime.
Am Tue, Aug 09, 2022 at 11:32:56PM +0200 schrieb Maxime Devos:
> I am not aware of such a preference, do you have a source?
No, it was just an impression I got from discussions on the mailing list.
So I am unsure if there is an official position, and do not know what
to do here...
Andreas
Hello, I just pushed your update to python-sympy, after trying to recompile all its dependents and verifying that they mostly do not become broken. Andreas
Hello, Am Wed, Aug 03, 2022 at 11:21:43AM +0200 schrieb guix@ikherbers.com: > As for gap, I took another stab at it and it now builds reproducibly for > me. I also removed all the trailing #t's and changed the phases to use a > gexp. today I looked at gap. Since there were many whitespace changes, I found it a bit difficult to review, and copied only the most relevant/easiest parts of your commit. In particular I did not move to gexps, which could be done in a separate patch. So far I also did not apply the part for making the build reproducible, which could be done in yet another patch. > By the way, the gap definition contains a snippet that deletes many gap > packages over concerns due to missing explicit licenses. However in a > cursory look at the tarball, I can see many LICENSE/COPYING files so > that may have changed. Yes, there is an ongoing effort in GAP to clarify the license situation, with apparently a lot of progress in this release. I have added (hopefully) all packages with a free license and which do not require additional inputs. We could go further; for instance add ZeroQMInterface (which requires zeromq) and dependent packages, CddInterface (which I suppose requires cddlib) and then NConvex, but I am a bit weary of adding dependencies, even more so since we do not seem to have GAP users in Guix who could give us feedback. It would be more motivating with users who confirm that the packages do not only load, but actually work as expected... Andreas
Hi I've checked, build and pushed 8 packages to master from https://issues.guix.gnu.org/70924. Let's refresh this series as well and maybe we may pack just new not-dependent packages out from "v3 32" series? -- Thanks, Oleg