Staged-recipes: Package sagemath

[ocefpaf]

Sagemath has a huge number of dependencies, so it is going to take time to get all dependencies to conda-forge.

:+1: to your effort in bringing sagemath to conda-forge! It will be an awesome addition!! Please ping me foe help.

[jakirkham]

This sounds awesome. Would love to be able to conda install sage. 😄

[jakirkham]

So there is ssl_match_hostname, which is a backports package. I don't know if that fits your requirements above or if that is a different package altogether.

[isuruf]

@jakirkham, thanks. I searched backports and it didn't come up. If there are more like that, please let me know.

[jakirkham]

Of course, nothing else it popping out at me ATM, but will let you know.

[jakirkham]

Figured you might be interested in this, @williamstein. 😉

[williamstein]

yep!!!!!!!

[jakirkham]

@minrk, do you have any thoughts on packaging mathjax?

[minrk]

@jakirkham since mathjax is javascript, I think it makes more sense to follow javascript practices of bundling it in the packages that depend on it (as is done in jupyter-notebook), rather than making it its own package. Pulling javascript dependencies out into their own packages seems to cause headaches where that's done (in debian, at least).

If you wanted to do it, though, a simple recipe that should work:

build:
  script: npm install -g mathjax
dependencies:
  build:
    - nodejs

Which might need to be spelled slightly differently to do download and local install, rather than download in the install command, but that's the gist.

[jakirkham]

Also @isuruf some of the Flask packages are named flask_*. Should it be _ or should it - as it seems many things are using -.

[jakirkham]

So is there any risk from having two packages that both bundle the same JavaScript dependency, @minrk? Could you please elaborate a bit on the problems that are caused by having the JavaScript dependencies as separate packages?

[isuruf]

Yes, I'll use - which seems to be the norm for conda packages. The names listed above are what sage uses and for some of them, I've used different names where appropriate

[jakirkham]

Was mainly referring to the Python packages to be clear (particular Flask packages). In those cases, it seems the authors chose -. As for the rest am fine using whatever name correctly conveys the typical name for the dependency.

[minrk]

So is there any risk from having two packages that both bundle the same JavaScript dependency, @minrk?

Only wasted disk space, I think.

Could you please elaborate a bit on the problems that are caused by having the JavaScript dependencies as separate packages?

Mainly version requirements and not behaving like the 'normal' package. Any time that your package behaves differently from a normal installation is a source of added complexity to deal with. One potential issue: with npm's behavior, each application should be able to have its own different version of a dependency. With conda, you can't have several different versions of the same package installed in the same env, but you may need to to serve the requirements of two packages with the same dependency.

[isuruf]

Now that all the build-time dependencies are there (except for libgap which I'll add after figuring out why there are test failures), I tried building sage on travis and circle.
I can't compile sage on travis-ci due to the time limit.
On Circle-CI I get an error, but can't see the output at the end because the output > 4 MB. Is there a way to get the output at the end?

[embray]

@isuruf Thanks for all your awesome work on this. When I get back from vacation in a week I hope to spend some time helping with some of the remaining packages. I think it's already been mentioned but there is a Sage Days on packaging coming up later this month in France. I would encourage you to participate, if you're at all available, even if remotely. That would be a good time for me too to sprint on this. At the last packaging Sage Days a year ago we even discussed Conda as a likely target for packaging Sage, but nobody really had the time / expertise to really make a go at it at the time, myself included (despite having working on a few conda packages several years ago).

[isuruf]

I thought I won't be able to make it, but it seems I can from Wednesday. Unfortunately there's no time to apply for visa. So, I'll join remotely.
I'll do giac, giacpy_sage, sympow and conway_polynomials this weekend. I'll need some help with maxima. Sage's maxima is not the latest and I'd like to package the latest version.

[embray]

@isuruf Updating maxima may be non-trivial, but I'll give it a try and see what happens.

[isuruf]

@embray, then we can have the same version as sage.

[embray]

@isuruf The maxima currently in Sage's develop branch is already 5.39.0, the latest version as far as I can tell. So this will be in the Sage 7.6 release which is already at rc0. So maybe that should be targeted anyways for the Sage conda package, in which case we should go ahead and package maxima 5.39.0

[embray]

All that said, I'll go ahead and work on Maxima. Thanks again @isuruf for the amazing amount of work you've already done on this!

[embray]

I'm close to having a working Maxima package--there's just one test that fails in make check, in tests/rtest.mac:

2152 /* Catalan's constant: 0.915965594... */
2153 closeto(li[2](1.0*%i) - (-%pi^2/48 + %i*0.915965594177219015054603514932384110774149374281672134266), 1.3878e-16), numer;
2154 true;

For some reason when I manually call li[2](1.0*%i) I get:

(%i1) li[2](1.0*%i);

Maxima encountered a Lisp error:

 #<a DIVISION-BY-ZERO>

Which doesn't seem right (see http://maxima.sourceforge.net/docs/manual/maxima_10.html#Item_003a-li) So maybe this is a bug in Maxima? Not sure though.

[jakirkham]

The maxima currently in Sage's develop branch is already 5.39.0, the latest version as far as I can tell. So this will be in the Sage 7.6 release which is already at rc0. So maybe that should be targeted anyways for the Sage conda package, in which case we should go ahead and package maxima 5.39.0

The main thing I would add is it would be nice if the first release of the Sage package is a formal (non-dev) release. So if you think by the time we get these dependencies done 7.6 will be ready, that should be fine. Otherwise we might be better off starting with a version of maxima that works with Sage 7.5 and then upgrading maxima in the feedstock. Just something to think about.

[isuruf]

I think sage-7.5 would also work with latest maxima.

[embray]

To follow up on this comment: https://github.com/conda-forge/staged-recipes/issues/2357#issuecomment-286808427 I can't reproduce it on the same version of Maxima but that I built outside conda. That leads me to believe it might even be a problem with the particular version of gmp that was used. I'll go ahead an post a PR for the Maxima package and follow up further from there...

[embray]

The main thing I would add is it would be nice if the first release of the Sage package is a formal (non-dev) release. So if you think by the time we get these dependencies done 7.6 will be ready, that should be fine.

My bet is that it will take long enough to get the last bits working that it would make sense to target Sage 7.6 as the baseline, as it will probably be out before long anyways.

[embray]

While we wait on feedback for #2621 I'll see about working on sympow.

[saraedum]

@isuruf: I think the listing in the issue needs some updating. Everything is packaged now, right?

[jakirkham]

Did a quick pass and I think everything in the "New packages needed" section is completed. Have xref'd PRs and checked these off. Everything else that wasn't already checked off or not in that list is still open.

[isuruf]

I've moved the last few items to https://github.com/conda-forge/sage-feedstock/issues/2. They are not essential to run sage, and sagenb is not used anymore anyway.

Thanks everybody for helping and for the reviews