2013/7/4 Ondřej Čertík <ondrej.cer...@gmail.com> > Hi Ronan, > > On Wed, Jul 3, 2013 at 1:52 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: > > I've stayed silent until then, but this discussion is getting annoying. > > First of all, I am very sorry if we or I annoyed you. That was not my > intention, > all I want is to rationally discuss pros and cons of unbundling mpmath. >
That's the thing. I don't think you're being rational on this issue. You seem to claim the benefits both of forking and of not forking mpmath. With the current situation, we get neither. > For this I would like to thank you Sergey, that we kept the discussion > based > on rational arguments and mutual respect. > > > I'm starting to think that the only way to restore sanity is to fork > sympy. > > Well I would be very sad if we can't resolve things, especially since we > agreed > on everything except the last point of actually removing mpmath completely. > Well, I think there's room for a light-weight, more modular version of sympy. But don't worry, I don't have the time to actually do it. > 2013/7/3 Ondřej Čertík <ondrej.cer...@gmail.com> > >> > >> 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. :) > > > > > > No, it's not. As you pointed out yourself, sympy.mpmath and mpmath are > not > > the same thing. > > > >> > >> It started as part of SymPy and so far we > >> have been treating it as part of SymPy. > > > > > > No, we have not. Current policy is not to modify anything in > sympy.mpmath. > > I guess the correct way to put it would be: Ondrej did but Ronan didn't. ;) > > >> 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. > > > > > > If mpmath does not have many users, it's in part because sympy robbed it > of > > its users (it's basically impossible to use the real mpmath together with > > sympy) > > We all already agreed that we should fix this, so that sympy can be easily > used with externally installed mpmath. > > >> > >> > >> >> It could and it should, but arguably mpmath gets much better testing > >> >> when many of sympy users run our test suite. > > > > > > No, mpmath doesn't get any testing by sympy users, because what they use > is > > sympy.mpmath, not mpmath. > > Which, as you pointed above, the policy is not to modify sympy.mpmath, > or a least > send the patches upstream, as we did. I doubt that all the patches have been sent upstream. In any case, patches to mpmath have not been applied to sympy.mpmath, so what is tested is not mpmath. (and even if sympy.mpmath were a perfect copy of some version of mpmath, "sympy.mpmath is not mpmath" would still be True) So mpmath does get testing by sympy users. > > >> > >> 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. > > > > > > Making it an option is not a solution. It might help packagers but it'll > > make the code for installation even more complicated, and force us to > test > > both versions. > > I haven't thought about this before, but you are right. If we start > depending on mpmath as an external project, then we have to test all > versions that we decide to support. So that's a major pain and that is > a great argument why we should include a version of mpmath in sympy > and making sure that this particular version works great with sympy on > all platforms and Python versions. > We already have that problem with all our "optional" dependencies. > > > > >> > >> 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. > > > > > > It would make *my* life easier, because the code for testing and > installing > > would be seriously simplified. > > Are we talking about > > python setup.py install --no-mpmath > > versus > > python setup.py install > > or about something else? > I'm talking about the code inside setup.py and everything that it calls. > > > > >> > >> 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. > > > > > > It's "pip install sympy" in one case and "pip install sympy" in the > other. > > You can call it more complex if you like, but it's not strictly more > > complex. > > That's if you use virtualenv. Many times I install from tar.gz or git, > and many times offline. > You can use pip without virtualenv. You can also install from git or from a local .tar.gz. > In all these cases, it will be more complex. Other users install .exe > on Windows. > And so on. > > Anyway, I think the conclusion is clear -- make it so that sympy can > use external mpmath, then we'll go from there. Well, if we do that, we'll have to support all relevant versions of mpmath, so we don't gain anything compared to just depending on it. Also, this will certainly require fixing the interaction between sympy.mpmath and mpmath, which means modifying sympy.mpmath. It seems that you actually want sympy.mpmath to be a fork of mpmath, and a fully integrated part of sympy, so why don't you just say so? -- 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.
