On Sat, Jun 29, 2013 at 1:52 AM, Sergey B Kirpichev <skirpic...@gmail.com> wrote: > On Fri, Jun 28, 2013 at 09:38:35PM -0500, Ondřej Čertík wrote: >> >> That being said, if projects like binstar (https://binstar.org/), >> >> which was announced *yesterday*, take off and allow easy >> >> installation on all platforms (including Windows...), we can revisit >> >> this. Clearly, the issue of distribution of packages has not been >> >> fixed *today*. >> > >> > I don't see any reasons why this new project is an argument. Can >> > you list some real problems (better for python >= 2.5)? >> >> One of them is for example that sympy.mpmath has received 13 patches >> since the last release of mpmath 0.17 over 2 years ago: >> >> ondrej@eagle:~/repos/sympy/sympy/mpmath(master)$ git shortlog -ns >> --since="February 2011" . | wc -l >> 13 > > It's also - not an argument in favor of some mystical > problems with mpmath's installation.
Well I think it is --- these patches are not in the latest release of mpmath. Projects like binstar will hopefully provide easy means for people to contribute releases and binaries for all platforms. Currently the easiest way for us has been to maintain our own version of mpmath, making sure the codebase is up-to-date and contributing our patches back to mpmath. > > Actually, this just means that we have mpmath fork. That's right. > >> At the moment we don't seem to have the manpower to also >> manage a release of another external project (mpmath). > > Do you think, that mpmath is not supported well? I CCed Fredrik, so that he can join the discussion. Look, the whole problem of any project is to manage its dependencies well. This is a deep problem, that one has to very carefully weigh pros and cons. 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: ondrej@hawk:~$ wajig dependents python-mpmath s python-mpmath-doc So it's the mpmath (documentation) itself. Compare it's popularity: http://qa.debian.org/popcon.php?package=mpmath versus sympy: http://qa.debian.org/popcon.php?package=sympy As such, sympy is the only project that actually depends on mpmath, and also sympy is vastly (e.g. more than 5x according to the stats) more popular. So the result is that 80% of all people will have to bother installing mpmath, which otherwise they would not use separately. As such, that is not a healthy dependency. At least not yet. Now compare this for example with numpy. Let's list all packages that depend on it: ondrej@hawk:~$ wajig dependents python-numpy d python-numpy-dbg d cain d castle-combat d childsplay d code-aster-run d connectomeviewer d dicompyler d eficas d epigrass r expeyes d fofix d fonttools d gausssum r gnudatalanguage d grass s ipython d labyrinth d libsyfi1.0-dev d mayavi2 d memaker d mmass d model-builder d mypaint d ninix-aya d novnc d nulog d pdb2pqr d psychopy d pybik s pykaraoke d pymca d pymca-data s python-aubio d python-biopython d python-biosig d python-brian d python-brian-lib d python-cclib d python-cfflib d python-chaco d python-cmor d python-cogent d python-csa r python-dballe r python-dicom d python-dipy d python-dolfin d python-enable d python-epr d python-fabio d python-ferari d python-fiat d python-freenect r python-gamera d python-gdal d python-getfem++ d python-gnuplot d python-guiqwt d python-h5py r python-instant r python-joblib d python-magics++ d python-mathgl d python-matplotlib d python-mdp d python-mlpy d python-mlpy-lib s python-mpi4py d python-mpikmeans d python-mvpa d python-mvpa-lib d python-mvpa2 d python-mvpa2-lib d python-necpp r python-networkx d python-nibabel d python-nifti d python-nipy d python-nipy-lib d python-nipy-lib-dbg d python-nitime s python-nltk d python-numexpr s python-opengl d python-openopt d python-pandas d python-pandas-lib d python-pebl d python-plplot d python-plplot-qt d python-pybiggles d python-pyentropy d python-pyepl r python-pyevolve d python-pyfits d python-pygame d python-pygetdata d python-pygrace s python-pykaraoke d python-pymt d python-pytango d python-pytools d python-pytrilinos d python-pywt d python-qwt5-qt4 d python-rpy d python-rpy2 d python-scikits.statsmodels d python-scipy d python-scipy-dbg d python-scitools s python-shapely d python-sidl d python-sklearn d python-sklearn-lib d python-sparse d python-sphere r python-spyderlib d python-stfio d python-swiginac d python-syfi r python-sympy d python-tables r python-uncertainties d python-vigra d python-viper d python-visual d python-whiteboard d pytrainer r qiime r science-mathematics-dev r science-numericalcomputation r screenlets-pack-all r screenlets-pack-basic d sfc d shogun-elwms-static d shogun-python-modular d shogun-python-static d singularity d snowballz d specto d stimfit d tpclient-pywx d veusz d veusz-helpers d vistrails d vitables d wsjt d wxbanker d wxgeometrie d yade d mgltools-gle d mgltools-molkit d mgltools-opengltk d mgltools-pyautodock d mgltools-sff d mgltools-symserv d mgltools-volume d python-pygpu d python-pyopencl d sixpack d python-numpy-dbg r gnudatalanguage d grass d libsyfi1.0-dev d mayavi2 d mypaint d ninix-aya d novnc d pdb2pqr d pybik d pymca s python-aubio d python-biopython d python-biosig d python-brian-lib d python-chaco d python-cmor d python-cogent r python-dballe d python-dolfin d python-enable d python-epr d python-fabio d python-freenect r python-gamera d python-gdal d python-getfem++ d python-guiqwt d python-h5py d python-magics++ d python-mathgl d python-matplotlib d python-mlpy-lib s python-mpi4py d python-mpikmeans d python-mvpa-lib d python-mvpa2-lib d python-necpp d python-nifti d python-nipy-lib d python-nipy-lib-dbg d python-numexpr d python-pandas-lib d python-pebl d python-plplot d python-plplot-qt d python-pybiggles d python-pyepl d python-pyfits d python-pygame d python-pygetdata s python-pykaraoke d python-pymt d python-pytango d python-pytrilinos d python-pywt d python-qwt5-qt4 d python-rpy d python-rpy2 d python-scipy d python-scipy-dbg s python-shapely d python-sidl d python-sklearn-lib d python-sparse d python-sphere d python-stfio d python-swiginac d python-syfi d python-tables d python-vigra d python-visual r qiime d shogun-elwms-static d shogun-python-modular d shogun-python-static d stimfit d veusz-helpers d wsjt d yade d mgltools-gle d mgltools-opengltk d mgltools-sff d python-pyopencl r inkscape s pitivi s ibid d python-netcdf d python-qwt3d-qt4 d python-scientific d python-scientific-doc r inkscape d python-netcdf d python-qwt3d-qt4 d conservation-code d python-pycuda d python-pycuda r inkscape And its popularity: http://qa.debian.org/popcon.php?package=python-numpy So that's a healthy dependency in the sense that we should not include sources of numpy in our project, but rather depend on it if needed. By ignoring all this and just seeing "mpmath" in sympy sources and thus requiring that we remove it and hard depend on it, would not be a wise decision. Again, I am repeating what the blogpost that I linked above discusses, I encourage you to read it and think about the arguments. > >> There is another big problem, that I hadn't mentioned before. At the >> moment, you can use git bisect and go into history of sympy and easily >> figure out if something broke. The moment we start depending on >> mpmath, and we commit just one fix that breaks sympy (by adding it to >> mpmath directly and creating a new release), the git bisect stops >> working, and different sympy git hashes will depend on different >> versions of mpmath. That will be a huge nightmare. > > We already have this situation for others external dependecies. > >> Another issue, mentioned by Fredrik in the issue is that currently >> mpmath is tested with sympy. > > Are you about sympy/mpmath/tests/*? Yes. > Why this can't be tested with > travis for a separate project? It could and it should, but arguably mpmath gets much better testing when many of sympy users run our test suite. Again, if we were talking about numpy, then my argument would be quite ridiculous, in the light of the stats that I discussed above, because vastly more users install numpy than sympy. But we are talking about mpmath, and there it stands, because at least 80% of Debian users only install sympy, not mpmath. Now for projects like Debian or Fedora, which do allow easy dependency installation, we should provide an easy switch in our setup.py. That way they can manage mpmath at one place and any Debian specific patches and fixes that they contribute will automatically apply to sympy. But this is specific to Debian/Fedora, as well as homebrew and other distributions like Anaconda. On other platforms the users would have to install mpmath from its webpage, so they will have an older version than it is in sympy. Any security fixes that you mentioned (as one possible worry), we would simply apply to sympy itself. 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. 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.
