This is an ebuild for sympy-0.5.3 (not yet in the tree). SymPy is a Python library for symbolic mathematics.
Created attachment 131131 [details] sympy-0.5.3.ebuild attaching ebuild
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/sci-libs/sympy/
I've successfully emerged sympy-0.5.7 by renaming the ebuild from sunrise. Please bump the version.
(In reply to comment #3) > I've successfully emerged sympy-0.5.7 by renaming the ebuild from sunrise. > Please bump the version. bumped to 0.5.8 in sunrise, should show up once it gets reviewed
*** Bug 203111 has been marked as a duplicate of this bug. ***
Created attachment 140209 [details] sympy-0.5.10.ebuild
Ebuild for sympy-0.5.10 attached. The old one created by Thomas won't work with this version as installation procedure has changed. I have renamed xslt USE-flag to mathml and added new flags: examples, latex and plot. Also added support for package testing (requires dev-python/py). Removed dev-python/ipython from dependencies list. This package in only recommended as the default shell for sympy. I have added a notice for this (see ebuild, lines 90-97). Maybe a USE-flag ipython for this purpose would be better?
Created attachment 140218 [details, diff] proposed changes for Mateusz' ebuild (In reply to comment #6) > Created an attachment (id=140209) [edit] > sympy-0.5.10.ebuild > Hi Mateusz, thanks a lot for your ebuild. I've attached some proposals for your ebuild, please tell me if you have any objections and/or questions. Also, I'd like to get the new ebuild into sunrise. Are you OK with this? Of course, you can do it yourself if you have commit access to sunrise.
(In reply to comment #8) > Created an attachment (id=140218) [edit] > proposed changes for Mateusz' ebuild The only objection I have about math USE-flag. We use libxml2 and libxslt for matml generation from sympy expressions (and in printing using gtkmathview). So 'math' is a bit meaning less. However if 'mathml' can't be used for some reason (eg. finite set of local USE-flags?) then 'xslt' would be much better. Besides that the updated ebuild looks much clearer, so feel free to apply your changes and please commit it (this is the first ebuild I've written so I don't have access to any repositories). btw. When sympy will be added to main portage tree, then I should propose updated ebuilds in separate bugs? Thanks for help, Mateusz
(In reply to comment #9) I've chosen 'math' because 'mathml' isn't used by any package yet, while two have a local 'math' USE-flag to enable math rendering: app-office/abiword-plugins:math - Enable gtkmathview support www-apps/mediawiki:math - Adds math rendering support xslt is used by www-misc/nsxml and dev-ruby/nitro to enable xslt support. I'll talk to some dev about which one to use. > Besides that the updated ebuild looks much clearer, so feel free to apply your > changes and please commit it (this is the first ebuild I've written so I don't > have access to any repositories). > Well, I don't have any commit access (except sunrise) either. sunrise is a dev+user driven overlay, you can read about it here: http://overlays.gentoo.org/proj/sunrise > btw. When sympy will be added to main portage tree, then I should propose > updated ebuilds in separate bugs? > Yes, with one exception: Let's assume you open a new bug for sympy 0.5.11 and then, before this new bug gets fixed, 0.5.12 is published. You can then of course continue in the existing bug. And until sympy gets in the main tree just do the version bump here.
(In reply to comment #10) > I'll talk to some dev about which one to use. OK. Looking forward to their opinion. > Well, I don't have any commit access (except sunrise) either. I will try to get to sunrise to take care of sympy in longer term.
sympy-0.5.11 has just appeared. I think the USE flag name "math" is not appropriate here. sympy has several ways to produce nicely rendered maths - at least LaTeX, mathml, TeXmacs. mathml is only one of them. So, the name of the USE flag must be more specific. I think "mathml" is a good name. 0.5.10 has added a TeXmacs interface. I think we also need a USE flag "texmacs", to depend on TeXmacs conditionally, and to install the sympy plugin into its proper place in /usr/share/TeXmacs/plugins/ and /usr/libexec/TeXmacs/bin (if necessary; I have not yet studied this plugin, and don't know if it contains scripts which go to /usr/libexec/).
Created attachment 142595 [details] sympy-0.5.12.ebuild Here's an ebuild for 0.5.12 based on Mateusz' work. I've asked on gentoo-devhelp about the USE-flags ([1]), in short: mathml for MathML-rendering, texmacs for the TeXmacs plugin. There's no plot USE-flag because sympy assumes pyglet and its dependencies are met. Would be nice if someone could try the texmacs plugin, it worked for me but I've never used TeXmacs before. [1] http://archives.gentoo.org/gentoo-devhelp/msg_09277158c26ac96a0b1af38b778584ff.xml
(In reply to comment #13) Uh, ah, forgot: TeXmacs will most probably fail to build because of bug #163907. I've used the 1.0.6.12-r1 ebuild from Science Overlay ([1]). I'm also unsure whether I should commit this to Sunrise (because it depends on obviously broken texmacs). I'll try to get some comments on #gentoo-sunrise. For the time being, it stays in bugzilla only. [1] http://overlays.gentoo.org/proj/science
Funny. I made practically the same ebuild yesterday, and was going to put it here today. I think the use flags latex, texmacs, mathml nicely correspond to 3 ways sympy has to typeset maths: LaTeX, TeXmacs, mathml. In my ebuild, I used NEED_PYTHON=2.5: I already switched to 2.5, and don't want stuff to be compiled for 2.4. Concerning TeXmacs, the ebuild in the mainline tree is incredibly old and ugly, it does not work with recent versions of maxima, etc. etc. I wonder when my ebuild from the science overlay will go to the mainline. By the way, don't you think that sympy belongs to dev-python more naturally than to sci-libs?
Forgot to say: the TeXmacs plugin works for me
(In reply to comment #15) > I used NEED_PYTHON=2.5: I already switched to 2.5, and don't want stuff to be > compiled for 2.4. NEED_PYTHON adds >=dev-lang/python-${NEED_PYTHON} to {R,}DEPEND. distutils eclass will always install to the `right' libdir: pylibdir="$(${python} -c 'from distutils.sysconfig import get_python_lib; print get_python_lib()')" > By the way, don't you think that sympy belongs to dev-python more naturally than to > sci-libs? Main reason for putting it there was that scipy was already there :).
Hi I'm willing to maintain sympy in the main tree, it looks like a package with good momentum. The ebuild looks good, but still needs a bit of work. Here are some comments to improve it: - DEPEND should not need all the RDEPEND stuff, probably none of it actually - use some die functions when installing stuff (doexe, doins) - examples in /usr/share/doc/${PF} - RDEPEND forces a dep on imaging and pyopengl. Are they really necessary to have a running sympy? - do we really need a python_mod_cleanup for the examples? In general, the dependencies are not well documented upstream, so may be someone could clarify. It seems that it needs numpy for matrices, and why pyglet and mathmp are in thirdparty and not as required dependencies?
(In reply to comment #18) > I'm willing to maintain sympy in the main tree Great. Looking forward to your initiative. > In general, the dependencies are not well documented upstream That's true. > It seems that it needs numpy for matrices No, numpy isn't required, however sympy can cooperate with numpy arrays. > RDEPEND forces a dep on imaging and pyopengl (...) [1] To run sympy you need only python 2.4 or better [2] ctypes, pyopengl and imaging are required in plotting module [3] pexpect is required in printing.preview module Both [2] and [3] are not needed at startup. > why pyglet and mathmp are in thirdparty and not as required dependencies [1] pyglet is a very nice package but still very unstable, so we maintain a copy of it in thirdparty to have the most recent version available (we have found many bugs in it during development of plotting and preview modules). Anyway pyglet is not yet available in portage. However there is a preliminary ebuild for it (see #207125). [2] mpmath is not available in portage so we need a copy of it (in fact mpmath was a sympy module, see numerics module which is still in the tree). > DEPEND should not need all the RDEPEND stuff, probably none of it actually Yes, DEPEND should contain dev-python/py and additionally packages required by plotting module (via a USE-flag) for testing purpose. In sympy, tests which require external packages are enabled only when appropriate packages are installed on the system. > use some die functions when installing stuff (doexe, doins) > examples in /usr/share/doc/${PF} Will be fixed.
(In reply to comment #18) > I'm willing to maintain sympy in the main tree, it looks like a package with > good momentum. Great! > Here are some comments to improve it: > - DEPEND should not need all the RDEPEND stuff, probably none of it actually yep, I was unsure about the test-dependencies, but Mateusz cleared it up now. As for the plotting-USE-flag, see below. > - use some die functions when installing stuff (doexe, doins) i thought there's no need for die with do* functions? There are lots of them in the devmanual example [2] without || die. > - examples in /usr/share/doc/${PF} yep. > - RDEPEND forces a dep on imaging and pyopengl. Are they really necessary to > have a running sympy? Mateusz, please correct me if anything is wrong here: imaging and pyopengl are not necessary at startup, but sympy will fail (ungracefully) when loading the plotting module. There is no way to, e.g. --disable-plotting, so I haven't made it USE-dependent. Peter Volkov cited ([1]) from devmanual: "Often the configure script will try to automatically enable support for optional components based upon installed packages. This *must not* be allowed to happen." > - do we really need a python_mod_cleanup for the examples? If you run any of the examples, you'll get the *.pyc files in there, leaving the directory untouched on unmerge (because it's not empty). Hmmm.... but actually this should go in pkg_prerm then, shouldn't it? [1] http://archives.gentoo.org/gentoo-devhelp/msg_09277158c26ac96a0b1af38b778584ff.xml [2] http://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html
(In reply to comment #20) > imaging and pyopengl are not necessary at startup, but sympy will fail > (ungracefully) when loading the plotting module. There is no way to, e.g. > --disable-plotting sympy has no startup dependencies (besides python itself of course). Note that by default all available modules are loaded (both when import sympy or in isympy), including plotting. However if ctypes package is not installed then during import plotting a dummy function Plot() will be created (hiding Plot class), which will raise a graceful exception (at call time). Both imaging and pexpect are being imported at function call time (in Plot.saveimage() and preview() (and friends) respectively). In case of pyopengl I had outdated information and so it's no more needed.
version bump: sympy-0.5.13 Interesting changelog: http://code.google.com/p/sympy/wiki/Changes Renaming the Thomas Pani's ebuild (sympy-0.5.12) works for me. Thanks
version bump: sympy-0.5.14 Could someone please summarize the remaining issues keeping this package from the main portage tree?
sympy-0.5.15 version bumb. Renaming Thomas Pani ebuild works for me. Thanks Thomas!
Sympy 0.6.0 and 0.6.1 have been released. Simply renaming the old ebuild seems to work. Is it OK to list this bug as InOverlay as the version in sunrise is very old and outdated (0.5.8)? The package may be in sunrise overlay, but it is certainly not maintained.
(In reply to comment #25) > Is it OK to list this bug as InOverlay as the version in sunrise is very old > and outdated (0.5.8)? The package may be in sunrise overlay, but it is > certainly not maintained. > Very true ;) . I just commited 0.6.1 to sunrise, should be in the reviewed branch soon.
I've committed sympy-0.6.2.ebuild to the portage tree. With USE=doc html documentation is generated (by sphinx) and installed. The ebuild I've committed still uses mpmath and (subset of) pyglet supplied with sympy. This is not good. If anybody will produce patches needed to use system mpmath (in the tree) and system pyglet (in the science overlay at the moment), I'd be grateful.
(In reply to comment #27) > I've committed sympy-0.6.2.ebuild to the portage tree. > Thank you Andrey! Finally :)
