Regarding galgebra, at first it did languish quite a bit, but now it has been picked up by several people and is doing well https://github.com/pygae/galgebra. So I think the main issue is that for a package to do well on its own, it needs to have a strong community, which is independent of the SymPy community.
Aaron Meurer On Wed, May 6, 2020 at 1:20 PM Naman Nimmo <namanger...@gmail.com> wrote: > > Sounds good, I will add it to sympy.physics. > > Thanks all for your suggestions. > > > > On Thu, May 7, 2020, 00:48 Jason Moore <moorepa...@gmail.com> wrote: >> >> Gagandeep, >> >> Thanks for the consideration of my comments. >> >> Jason >> moorepants.info >> +01 530-601-9791 >> >> >> On Wed, May 6, 2020 at 12:13 PM Gagandeep Singh (B17CS021) >> <singh...@iitj.ac.in> wrote: >>> >>> Hi Jason, >>> >>> Thanks for presenting points on why sub-packages should be kept in the main >>> sympy repo. What I suggested was just an immature approach. Obviously, >>> there will be trade-offs in too much granulation of the codebase. I didn't >>> mean that what I suggested must be done. >>> >>> > It allows the code to be tested along with SymPy and be tied into the >>> > maintenance effort of SymPy. >>> >>> For example, the above is one of the trade-offs in carving out >>> sub-packages. Testing effort increases for each sub package. In fact, >>> sometimes bugs in independent sub-modules are routed to some of the core >>> modules of SymPy which leads to overall betterment of the code. Granulation >>> may make such things difficult to handle. >>> >>> > You can argue that maybe they should languish and die, but I don't think >>> > that is what we want. >>> >>> Ah! I think my points were mis-interpreted. I don't want any module to die. >>> >>> > There is the maintenance burden downside, but I think the positives far >>> > outweigh that negative >>> >>> That's quite a valid point that maintenance burden increases along with the >>> increase in the size of the code base. However, since from previous >>> experience, it has been observed that too much granulation isn't a good >>> idea then sure we can go with the current practices. >>> >>> May be, we can proceed as Aaron suggested, that is first control systems >>> can go into the main sympy repo. If in future it becomes sufficiently large >>> and has quite a good number of contributors, then we can think of carving >>> out, though at that time the situation will be very different and >>> trade-offs may change. >>> >>> On Thu, May 7, 2020 at 12:24 AM Jason Moore <moorepa...@gmail.com> wrote: >>>> >>>> Gangandeep, >>>> >>>> I disagree with your thoughts on this. We've dealt with this over a decade >>>> ago with the symbolic pydy package (which started as a separate package). >>>> After careful consideration we decided to add this to SymPy and it was the >>>> right decision. It allows the code to be tested along with SymPy and be >>>> tied into the maintenance effort of SymPy. It also ensures that the >>>> package can live on and will likely be used by end users. For packages >>>> that have very small development teams I firmly believe it is best to >>>> include in the larger SymPy development effort, otherwise the packages >>>> will languish and die. You can argue that maybe they should languish and >>>> die, but I don't think that is what we want. We want a strong broad >>>> community that contributes back to SymPy and having packages like these in >>>> SymPy helps that effort. There is the maintenance burden downside, but I >>>> think the positives far outweigh that negative. Another example is >>>> galgebra; I think that galgebra module should not have been removed, >>>> because now it suffers from lack of maintenance, developers, and users >>>> even though it is a very nice and useful package. If you remove all SymPy >>>> subpackages that are the leaves of the tree, there will not only be a lot >>>> of pruning of code but a lot of pruning of participating developers. The >>>> community is our #1 asset to being a popular package, not the code. One >>>> reason that Python itself is successful is that it is "batteries >>>> included". I think we should follow that same ethos with SymPy, i.e. >>>> "symbolic batteries included". >>>> >>>> Jason >>>> moorepants.info >>>> +01 530-601-9791 >>>> >>>> >>>> On Wed, May 6, 2020 at 10:39 AM Gagandeep Singh (B17CS021) >>>> <singh...@iitj.ac.in> wrote: >>>>> >>>>> Hi, >>>>> >>>>> IMHO, the control systems should go as a separate repository under sympy >>>>> with the main sympy repository as a dependency. >>>>> >>>>> In fact that should have happened with sympy.stats as well, as no other >>>>> module uses features of stats and the case is other way around but that >>>>> is a thing for another day. Well, I just thought of a way which could >>>>> have been used to organize modules. If we make a directed graph with >>>>> modules as nodes and an edge, m->n, would reflect that module n depends >>>>> on module m. Then only those modules should be kept under sympy/sympy >>>>> which have both in-degree and out-degree greater than 0. Those which have >>>>> out-degree of 0 can be carved out as separate packages under sympy >>>>> organization. However, as of now, doing this would create unnecessary >>>>> pain for end users. >>>>> >>>>> So, control systems, AFAICT will not be used by any other module under >>>>> main sympy repo, so can be kept as a separate package. >>>>> >>>>> On Wed, May 6, 2020 at 9:13 PM Naman Nimmo <namanger...@gmail.com> wrote: >>>>>> >>>>>> Hi everyone. >>>>>> >>>>>> Since the accepted GSoC projects are out now, and my project - "Control >>>>>> Theory - Implement a control systems package" was in that list, I would >>>>>> like to first know whether it will be a part of the main sympy project >>>>>> or some other project to go on PyPI? >>>>>> >>>>>> I personally feel It should belong to SymPy because it is symbolic in >>>>>> nature. >>>>>> I agree with what Aaron mentioned in the last thread: >>>>>> >>>>>> > An advantage of something being in SymPy itself is that it >>>>>> > automatically gets full development support from the rest of the >>>>>> > package, for instance, the tests for it are always run on Travis, it >>>>>> > is included in any package-wide refactorings, and so on. I would say >>>>>> > at the very least if there were to be a GSoC project that creates a >>>>>> > new package, then that package should go on under sympy org on GitHub >>>>>> > (github.com/sympy/new-package), so that the whole SymPy development >>>>>> > team has access to it >>>>>> >>>>>> What are your opinions? We can do what the whole community decides after >>>>>> considering all the advantages and the disadvantages of both options. >>>>>> >>>>>> Regards, >>>>>> Naman >>>>>> >>>>>> -- >>>>>> 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 view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/sympy/CALkUZDm4UGQz4P4Mg0XckpE2o7%2Bo8Ob26y7%2BxEWW31mNjOgYHA%40mail.gmail.com. >>>>> >>>>> >>>>> >>>>> -- >>>>> With regards, >>>>> Gagandeep Singh >>>>> Github - https://github.com/czgdp1807/ >>>>> Linkedin - https://www.linkedin.com/in/czgdp1807/ >>>>> >>>>> -- >>>>> 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 view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/sympy/CAAvS0gWrLcnfKhhd48gh-bG-MOusAq_St5%2BoeekApbtcSsE42w%40mail.gmail.com. >>>> >>>> -- >>>> 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 view this discussion on the web visit >>>> https://groups.google.com/d/msgid/sympy/CAP7f1AhWLiGLTUJioOU_d8ONp%3DEBdCdyU_3hejiExAsZXmKeiA%40mail.gmail.com. >>> >>> >>> >>> -- >>> With regards, >>> Gagandeep Singh >>> Github - https://github.com/czgdp1807/ >>> Linkedin - https://www.linkedin.com/in/czgdp1807/ >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CAAvS0gXdvVE4TPcBa7SuSf0aJKvfAVfTR%2BKXnBXfqPGD%3DPp_mA%40mail.gmail.com. >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAP7f1AhA-k%2B_TYW%2BkjhPz_nFf%2Bg6jMJmHa-LfP2qXV6nOJzMZw%40mail.gmail.com. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CALkUZDmviTKOncMYDrKjHeinffqzrUM%2BS9MirYd42zzexM09Nw%40mail.gmail.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JCCP7QXnsQFtdd3VMQRRz4oDUqcW55C6G53WXMqTY_Nw%40mail.gmail.com.
