+1 on Vincent's proposal. On Sunday, February 9, 2020 at 6:06:41 AM UTC-5, vdelecroix wrote: > > Concrete proposal for moving giacpy_sage into sage source > code at > > https://trac.sagemath.org/ticket/29171 > > Still some work to be done concerning indentation, > documentation formatting, code factorization, etc. > > Vincent > > Le 07/02/2020 à 13:06, Vincent Delecroix a écrit : > > I am in favor of moving giacpy_sage inside sage/libs. But it does > > not really fits Sage code standard. It is mostly undocumented > > and untested. > > > > This does not look so bad as most of the code is > > """ > > cdef class Pygen: > > > > def functionXYZ(self, *args): > > return GiacMethods['functionXYZ'](self, *args) > > """ > > > > Such thing could easily be automized together with the documentation > > (as long as it is available from giac in a standardized format). > > > > Best > > Vincent > > > > Le 07/02/2020 à 11:32, François Bissey a écrit : > >> I’ll claim responsibility for the name change request! > >> > >> More seriously, after reading this and thinking a little bit I would > >> really prefer if it was merged in sage/libs. The alternative means that > >> we have a true circular dependency sage <-> giacpy_sage and things > >> will start to get wild as soon as you want to build the docs. > >> sage the distro probably can shrug it off but us in linux distros will > >> go seriously banana about it. > >> > >> François > >> > >>> On 7/02/2020, at 11:04 PM, Han Frederic <frede...@imj-prg.fr > <javascript:>> wrote: > >>> > >>> First, thank you for this discussion. > >>> > >>> About the sage pip install project. The problem is that I don't know > >>> at all what will be available. > >>> But if you are done with sage's pyx files in src/sage/libs then it > >>> should be similar with giacpy_sage. > >>> > >>> It is indeed rare for an spkg to be linked to the sage library and > >>> giacpy_sage is > >>> more similar to the cython files in src/sage/libs than to an external > >>> package. > >>> > >>> The original ticket https://trac.sagemath.org/ticket/15226 six years > >>> ago about giacpy_sage > >>> was a sage patch. It just ended with no answer but with the current > >>> giacpy_sage > >>> it is still easy to put 4 files of giacpy_sage in sage's source tree > >>> src/sage/libs, adjust > >>> src/module_list.py and let sage's setup.py build giacpy_sage. Then > >>> you don't need an external package at all. > >>> > >>> This is related to Vincent's question. There are many cython files in > >>> sage/libs related > >>> to cypari2. Currently giacpy_sage have none. We need one of the > >>> following > >>> (to not lose any features) either giacpy_sage is an external package > >>> linked to the sage library > >>> or a part of giacpy_sage (or all of it, because it is just few files) > >>> is inside sage. Any of these > >>> solutions is fine for me. But being in between is more work and my > >>> skills and time are limited. > >>> > >>> > >>> The python package have a different name: giacpy. This was the only > >>> request I had during the previous vote where all the focus turned on > >>> giac and where giacpy_sage was forgotten. > >>> (cf > https://groups.google.com/d/topic/sage-devel/HI0uZra5_iI/discussion) > >>> I don't see any conflict in having both. Sage could load the python > >>> package but it is just less interesting than loading giacpy_sage. > >>> > >>> A minimal python is able to use the giacpy package obtain a full > >>> computer algebra system. I don't want to break this with the in > >>> between solution (1 python package and files in sage). > >>> It is important for me that a window user with no development tools > >>> looks to be able > >>> to do with a minimal python installation: > >>> python -m pip install giacpy > >>> > >>> and have it. It was very difficult for me to provides these binaries, > >>> and I don't want to break this. > >>> > >>> giac and sage are both computer algebra systems, so there have have > >>> many interactions that are meaningless in a standalone python. > >>> > >>> > >>> Another remark: giac is a standard package and giacpy_sage test it > >>> more. For instance this ticket > >>> https://trac.sagemath.org/ticket/27306 > >>> was a giac bug in a new version of giac. It was not related to > >>> giacpy_sage and I guess that it would have been detected during the > >>> upgrade of the giac package if giacpy_sage was standard, while it was > >>> detected after. > >>> > >>> Best > >>> > >>> Frederic > >>> > >>> > >>> -- > >>> 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-...@googlegroups.com <javascript:>. > >>> To view this discussion on the web visit > >>> > https://groups.google.com/d/msgid/sage-devel/f8f821da-50d7-4319-9477-57ff8a55fcfc%40googlegroups.com. > > > >>> > >> >
-- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f0f1de23-6363-46a5-9f63-d2c3ff5b0f7b%40googlegroups.com.
