Good to know! Jason moorepants.info +01 530-601-9791
On Wed, May 6, 2020 at 1:20 PM Aaron Meurer <asmeu...@gmail.com> wrote: > 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 > . > -- 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/CAP7f1AgCcn6%3D56n%2BWHDhUFwkgX0WkLTNS%2Bb4Poea_JY3d%2B%3DfYA%40mail.gmail.com.
