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 >> <https://groups.google.com/d/msgid/sympy/CALkUZDm4UGQz4P4Mg0XckpE2o7%2Bo8Ob26y7%2BxEWW31mNjOgYHA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > With regards, > Gagandeep Singh > Github - https://github.com/czgdp1807/ > Linkedin - https://www.linkedin.com/in/czgdp1807/ > <https://www.linkedin.com/in/gdp1/> > > -- > 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 > <https://groups.google.com/d/msgid/sympy/CAAvS0gWrLcnfKhhd48gh-bG-MOusAq_St5%2BoeekApbtcSsE42w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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.
