Re: [sage-devel] packaging vision (pip etc)
On 08/17/15 09:46, Ondřej Čertík wrote: And my next question is what should we do currently to make it easy for Sage users to install SymEngine. Should we continue using the spkg to install the C++ dependencies (cmake, the C++ libsymengine.so library) and then use pip to install the Python wrappers? As far as I can see the biggest obstacle is the inclusion of cmake in sage. While functionally equivalent autotools has a strong lead in mind share and length of its proven record. The fact that autotools doesn't need anything to be installed for the user deploying is also usually seen as a bonus. If you had 50 packages using cmake, having to install one more wouldn't seem such a bad deal but that's not where we are. Francois -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] packaging vision (pip etc)
On Tue, Aug 11, 2015 at 7:44 AM, William Stein wst...@gmail.com wrote: On Tue, Aug 11, 2015 at 1:15 AM, Volker Braun vbraun.n...@gmail.com wrote: [Top-posted to stop threadjacking the SymEngine post] I'm sorry for doing that -- it was sort of relevant to his question, but starting a new thread is much better. Just have the sage-python-library install using pip, assuming your system has all the dependencies, is almost trivial. The real question is always how to handle the dependencies, starting at a Fortran compiler. Also, just to establish a baseline for discussion, Daniel Holth (pip author) said: When people ask whether wheel can be used to distribute any other kind of software or dependency (libsdl, libqt, etc.) I recommend they take a look at system packaging tools or conda (comment at http://continuum.io/blog/conda_packaging). So IMHO the right solution is to first separate all the C/C++-level dependencies (gcc, pari, python itself,...) from the Python libraries. We still need a way to have a canonical stack of the C/C++ dependencies to test against and patch if necessary, but you could switch that for OS packages (if there is such a thing on your platform). There are various ways to do this, hashdist being one of them, and we can likely share at least some of the package maintenance effort with others. +1 -- this makes good sense. I like this. I was going to ask about it, because SymEngine depends on CMake, and that's not very practical to build using pip. Also, we are discussing to split the symengine C++ library and its Python wrappers into separate packages (so that the Python wrappers can be installed against multiple Python versions at once, if needed, and also so that other wrappers like Julia/Ruby can reuse the same C++ library --- it can be done already, but it's cleaner if it is separate). The C++ package can be installed using cmake and would be part of the C/C++ level dependencies. The Python wrappers would be installed using pip, and those would be tightly integrated with SymPy and Sage. That seems to be aligned with what Volker proposed. Let me know. Ondrej Then sage-the-python-library could just install itself and its Python dependencies with pip and requirements.txt That would be awesome. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] packaging vision (pip etc)
On Sun, Aug 16, 2015 at 3:33 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: On Tue, Aug 11, 2015 at 7:44 AM, William Stein wst...@gmail.com wrote: On Tue, Aug 11, 2015 at 1:15 AM, Volker Braun vbraun.n...@gmail.com wrote: [Top-posted to stop threadjacking the SymEngine post] I'm sorry for doing that -- it was sort of relevant to his question, but starting a new thread is much better. Just have the sage-python-library install using pip, assuming your system has all the dependencies, is almost trivial. The real question is always how to handle the dependencies, starting at a Fortran compiler. Also, just to establish a baseline for discussion, Daniel Holth (pip author) said: When people ask whether wheel can be used to distribute any other kind of software or dependency (libsdl, libqt, etc.) I recommend they take a look at system packaging tools or conda (comment at http://continuum.io/blog/conda_packaging). So IMHO the right solution is to first separate all the C/C++-level dependencies (gcc, pari, python itself,...) from the Python libraries. We still need a way to have a canonical stack of the C/C++ dependencies to test against and patch if necessary, but you could switch that for OS packages (if there is such a thing on your platform). There are various ways to do this, hashdist being one of them, and we can likely share at least some of the package maintenance effort with others. +1 -- this makes good sense. I like this. I was going to ask about it, because SymEngine depends on CMake, and that's not very practical to build using pip. Also, we are discussing to split the symengine C++ library and its Python wrappers into separate packages (so that the Python wrappers can be installed against multiple Python versions at once, if needed, and also so that other wrappers like Julia/Ruby can reuse the same C++ library --- it can be done already, but it's cleaner if it is separate). The C++ package can be installed using cmake and would be part of the C/C++ level dependencies. The Python wrappers would be installed using pip, and those would be tightly integrated with SymPy and Sage. That seems to be aligned with what Volker proposed. Let me know. And my next question is what should we do currently to make it easy for Sage users to install SymEngine. Should we continue using the spkg to install the C++ dependencies (cmake, the C++ libsymengine.so library) and then use pip to install the Python wrappers? Ondrej -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] packaging vision (pip etc)
On Sun, Aug 16, 2015 at 8:08 PM, François Bissey francois.bis...@canterbury.ac.nz wrote: On 08/17/15 09:46, Ondřej Čertík wrote: And my next question is what should we do currently to make it easy for Sage users to install SymEngine. Should we continue using the spkg to install the C++ dependencies (cmake, the C++ libsymengine.so library) and then use pip to install the Python wrappers? As far as I can see the biggest obstacle is the inclusion of cmake in sage. While functionally equivalent autotools has a strong lead in mind share and length of its proven record. The fact that autotools doesn't need anything to be installed for the user deploying is also usually seen as a bonus. If you had 50 packages using cmake, having to install one more wouldn't seem such a bad deal but that's not where we are. So now when we agreed to split the C++ library from the Python wrappers (and use pip for those), the C++ library itself is actually relatively easy to build, and so in principle we can also support autotools, especially if we only support the Release configuration using it. For development we would still use cmake. But I think getting cmake into Sage would be worthy, there are a lot of packages that use it and it has wide adoption (e.g. VTK, Paraview, Piranha, Armadillo, CGAL, Dolfin, Eigen, GiNaC, Gromacs, HPX, ITK, Lapack, LLVM, MPQC, Trilinos, ...). Even Google trends (I don't know if it is representative) shows that cmake is more searched than autotools/automake: https://www.google.com/trends/explore#q=cmake%2C%20autotools%2C%20automakecmpt=qtz=Etc%2FGMT%2B6 Ondrej -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] packaging vision (pip etc)
[Top-posted to stop threadjacking the SymEngine post] Just have the sage-python-library install using pip, assuming your system has all the dependencies, is almost trivial. The real question is always how to handle the dependencies, starting at a Fortran compiler. Also, just to establish a baseline for discussion, Daniel Holth (pip author) said: When people ask whether wheel can be used to distribute any other kind of software or dependency (libsdl, libqt, etc.) I recommend they take a look at system packaging tools or conda (comment at http://continuum.io/blog/conda_packaging). So IMHO the right solution is to first separate all the C/C++-level dependencies (gcc, pari, python itself,...) from the Python libraries. We still need a way to have a canonical stack of the C/C++ dependencies to test against and patch if necessary, but you could switch that for OS packages (if there is such a thing on your platform). There are various ways to do this, hashdist being one of them, and we can likely share at least some of the package maintenance effort with others. Then sage-the-python-library could just install itself and its Python dependencies with pip and requirements.txt -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] packaging vision (pip etc)
On Tue, Aug 11, 2015 at 1:15 AM, Volker Braun vbraun.n...@gmail.com wrote: [Top-posted to stop threadjacking the SymEngine post] I'm sorry for doing that -- it was sort of relevant to his question, but starting a new thread is much better. Just have the sage-python-library install using pip, assuming your system has all the dependencies, is almost trivial. The real question is always how to handle the dependencies, starting at a Fortran compiler. Also, just to establish a baseline for discussion, Daniel Holth (pip author) said: When people ask whether wheel can be used to distribute any other kind of software or dependency (libsdl, libqt, etc.) I recommend they take a look at system packaging tools or conda (comment at http://continuum.io/blog/conda_packaging). So IMHO the right solution is to first separate all the C/C++-level dependencies (gcc, pari, python itself,...) from the Python libraries. We still need a way to have a canonical stack of the C/C++ dependencies to test against and patch if necessary, but you could switch that for OS packages (if there is such a thing on your platform). There are various ways to do this, hashdist being one of them, and we can likely share at least some of the package maintenance effort with others. +1 -- this makes good sense. Then sage-the-python-library could just install itself and its Python dependencies with pip and requirements.txt That would be awesome. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
