Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package sagemath #2357

Closed
56 of 64 tasks
isuruf opened this issue Feb 6, 2017 · 30 comments
Closed
56 of 64 tasks

Package sagemath #2357

isuruf opened this issue Feb 6, 2017 · 30 comments

Comments

@isuruf
Copy link
Member

isuruf commented Feb 6, 2017

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

Some issues

New packages needed

Docs

  • thebe
  • tachyon

Sagenb

  • flask_autoindex
  • flask_oldsessions
  • flask_silk
  • jmol
  • mathjax
  • sagenb
  • sagenb_export

Other

  • sagetex
@ocefpaf
Copy link
Member

ocefpaf commented Feb 6, 2017

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

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

@jakirkham
Copy link
Member

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

@jakirkham
Copy link
Member

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
Copy link
Member Author

isuruf commented Feb 9, 2017

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

@jakirkham
Copy link
Member

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

@jakirkham
Copy link
Member

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

@williamstein
Copy link

yep!!!!!!!

@jakirkham
Copy link
Member

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

@minrk
Copy link
Member

minrk commented Feb 12, 2017

@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
Copy link
Member

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

@jakirkham
Copy link
Member

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
Copy link
Member Author

isuruf commented Feb 12, 2017

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
Copy link
Member

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
Copy link
Member

minrk commented Feb 13, 2017

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
Copy link
Member Author

isuruf commented Feb 25, 2017

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
Copy link
Contributor

embray commented Mar 3, 2017

@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
Copy link
Member Author

isuruf commented Mar 4, 2017

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
Copy link
Contributor

embray commented Mar 14, 2017

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

@isuruf
Copy link
Member Author

isuruf commented Mar 14, 2017

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

@embray
Copy link
Contributor

embray commented Mar 15, 2017

@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
Copy link
Contributor

embray commented Mar 15, 2017

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
Copy link
Contributor

embray commented Mar 15, 2017

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
Copy link
Member

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
Copy link
Member Author

isuruf commented Mar 15, 2017

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

@embray
Copy link
Contributor

embray commented Mar 15, 2017

To follow up on this comment: #2357 (comment) 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 embray mentioned this issue Mar 15, 2017
@embray
Copy link
Contributor

embray commented Mar 16, 2017

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
Copy link
Contributor

embray commented Mar 17, 2017

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

@saraedum
Copy link
Member

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

@jakirkham
Copy link
Member

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
Copy link
Member Author

isuruf commented Mar 27, 2017

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

Thanks everybody for helping and for the reviews

@isuruf isuruf closed this as completed Mar 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants