On Wed, Jul 3, 2013 at 11:23 AM, Sergey Kirpichev <skirpic...@gmail.com> wrote: > On Sun, Jun 30, 2013 at 11:04:03AM -0600, Ondřej Čertík wrote: >> > Actually, this just means that we have mpmath fork. >> >> That's right. >> >> [...] >> >> One should only depend on libraries, that are well supported and widely > used. >> Mpmath is not. For example on my Ubuntu, here are all the projects that > depend >> on mpmath >> >> [...] >> >> As such, sympy is the only project that actually depends on mpmath > > Taking into account all this. Do you think, mpmath should actually be > a separate project? > > If it's a pet project for sympy - why it's not just a part of sympy?
Well it is part of sympy. :) It started as part of SymPy and so far we have been treating it as part of SymPy. Fredrik eventually split it, kept it and supported it as a separate project and called it mpmath. Somebody then created a separate Debian package and so on. And that's fine, as mpmath does not depend on the rest of sympy, and if it is useful to at least some people outside of sympy, then why not make it available as a separate package too. > > If not, I don't think that the small current number of mpmath's users > (not total, but ones using mpmath AND NOT sympy) is an argument that > this project is not well supported and we should encourage forking. Matthew had a great lightning talk at SciPy 2013 about taking common code and taking it out of the big package into a separate project. There are lots of things in SymPy that can be taken apart. For example with some extra work, sympy.polys could be shipped as a separate package as well. Many things in sympy.utilities too, for example memoization.py etc. Also sympy.parsing could probably be made sympy independent (sympy would only register the sympify callback). So we can create all these little or bigger packages, like mpmath, memoization, polys, decorators, cythonutils, parsing. And make the user install all those in order to run sympy. I don't think it would make things simpler for the user. I think it would make things more complex. > >> It could and it should, but arguably mpmath gets much better testing >> when many of sympy users run our test suite. > > mpmath could run own test suite, in mpmath/tests/ (perhaps, we need a > patch for this?). There should be no decrease in test coverage at > least. > >> Now for projects like Debian or Fedora, which do allow easy dependency >> installation, we should provide an easy switch in our setup.py. > > Ok. I think, we got your points. Let's see, if there is other opinions. Now when my opinion is clear, can you clearly write your opinion as well? :) We have agreement on Debian/Fedora as well as that the size of mpmath is not an issue. We also have an agreement that for people like you (and others) who prefer to install it separately should have that option and it should be easy. So why do you want to make this extra step and remove it from sympy completely? Clearly it's not going to make *your* life any easier, since you'll already be installing mpmath separately. But you make it more complex for all the users who don't want to bother with mpmath and just want sympy to work. So I still don't understand your argument. > >> I apologize for the longer email, but this issue is something that I >> want to make clear, as it is my highest priority that sympy remains >> easy to use and install. > > Through, you don't provide any examples of difficulties with mpmath's > installation. Just the fact that you have to install it. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
