Aaron, The main challenge for the SymPy-PyDy codes is that we have to separate the symbolic and the numerical/visualization codes, with the numerical codes being in the external PyDy repository and that the PyDy tests are not run in the SymPy CI. It would be nice if all the code was together or if SymPy at least ran the PyDy tests against each SymPy PR. I think we could move sympy.physics.vector and sympy.physics.mechanics out of sympy and into PyDy and it would be ok at this point, but that's with the symbolic code being pretty stable and well used for a decade.
I think the model where we nurture niche packages in SymPy and then if they get popular enough they move to their own self supported repo is the best. We can always carefully deprecate and remove the package like we did with mpmath*. The only downside I see is the maintenance burden, but I think that burden is low and it is worth the benefits. We can also remove and delete packages permanently too if there don't seem to be any users. These should happen on major version changes to SymPy though. Including domain specific packages is good for end users. Its one of the reasons Matlab is so successful. The user installs one thing and has the core language and tools as well as all domain packages. Python struggles to this day with fractured packages and JS/Node is really struggling. If we want to be a competitor to Maple, Mathematica, etc. we should support domain specific packages. *mpmath was a self sustaining package that we vendored, but the removal model is a good one to follow. Jason moorepants.info +01 530-601-9791 On Wed, May 6, 2020 at 10:57 AM Aaron Meurer <asmeu...@gmail.com> wrote: > My suggestion would be to start with it in SymPy, since that will be > the easiest. You won't have to deal with setting up any of the > boilerplate that is required for a separate repository, like > packaging, setting up the testing and CI, and so on. > > The only concern is if we later want to move it out, if that would > present a challenge. I think Jason has the most experience with this > with PyDy and the sympy.physics.mechanics packages. I don't remember > if there was ever any major code that was moved from SymPy to PyDy or > from PyDy to SymPy. If there was, were there any challenges in this? > > Aaron Meurer > > On Wed, May 6, 2020 at 11:40 AM Jason Moore <moorepa...@gmail.com> wrote: > > > > Naman, > > > > I'd have a look at the maxima package. They likely have good and useful > ideas for your design. > > > > Jason > > moorepants.info > > +01 530-601-9791 > > > > > > On Wed, May 6, 2020 at 10:37 AM Javier Arantegui < > javier.arante...@gmail.com> wrote: > >> > >> Hello, > >> > >> it sounds interesting. > >> > >> What do you have in mind? Something like COMA < > http://www.austromath.at/daten/maxima/zusatz/coma.htm>? COMA is a control > engineering package for Maxima. > >> > >> I have my own script inspired in COMA to do some calculationl. It uses > sympy a lot. Honestly it's quite bad, but it makes my life easier. > >> > >> Javier > >> > >> > >> > >> On Wednesday, May 6, 2020 at 5:43:37 PM UTC+2, Naman Nimmo 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/3aa63a5a-10a2-49a4-9806-b4bc2cbd0d6d%40googlegroups.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/CAP7f1AjsN-iQnKdV98oHYaQVKa-_UWHvJXm6m8yuaRXtL8bd9g%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%3D6J5eK4G2Y4bPcg4SJThM-pC_QG-%2BYygxKU9AyBMuTgE-w%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/CAP7f1AgrM3FrGh-soPFzdyyWNQ9M7ccKvGBR%3D%2BZQT5LJ67jJuw%40mail.gmail.com.
