Hi Ronan,

On Wed, Jul 3, 2013 at 1:52 PM, Ronan Lamy <[email protected]> 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.
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.

> 2013/7/3 Ondřej Čertík <[email protected]>
>>
>> On Wed, Jul 3, 2013 at 11:23 AM, Sergey Kirpichev <[email protected]>
>> 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. So mpmath does get testing by sympy users.

>>
>> >
>> > 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.
>
>
> Size is irrelevant. Code duplication is an issue in itself.
>
>>
>> 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.

>
>>
>> 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?

>
>>
>> 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.
In all these cases, it will be more complex. Other users install .exe
on Windows.
And so on.


Sergey, I think I already stated my opinion to all your questions from
your last email, so just
briefly:

>> Now when my opinion is clear, can you clearly write your opinion as well? :)
>
> I thought, it was clear from beginning.  I prefer to unbundle mpmath.
> Reasons: nothing special.  If it's a stable external project - why we
> should fork it?
>

I stated all the reasons why we should include it in sympy in my
previous emails. If your only reason against is "nothing special", in
my opinion that's not good enough reason to make life more complex to
a lot of our users.

Ronan did state however a valid reason:

* code duplication

and I think that's your main reason as well, right? That is a valid reason, yes.



Anyway, I think the conclusion is clear -- make it so that sympy can
use external mpmath, then we'll go from there.

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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to