On Mon, Feb 3, 2020 at 2:02 PM Oscar Benjamin <[email protected]> wrote: > > On Mon, 3 Feb 2020 at 20:40, Aaron Meurer <[email protected]> wrote: > > > > This isn't against the rules of GSoC. However, I would caution against > > doing such a thing. Unless there are other people other than the GSoC > > student who are willing to help develop and maintain the package after > > the end of GSoC, the package has a very high risk of falling on the > > wayside. > > If no one is interested in maintaining the package then it will fall > by the wayside inside or outside of the main sympy repo. I think it's > better that happens outside so we don't end up with dead modules like > categories in the main repo.
These are valid points. There are certain types of submodules in SymPy which are leaves in the dependency graph. They are not used by other submodules, and would not conceivably be used by other submodules in the future. And they also aren't fundamental features of the package. The arguments for including these submodules in SymPy are much weaker than for other more "standard" submodules. Also I should point out that "control theory" is currently an idea on the GSoC ideas page. So that does imply that it's in scope for a project. > > > 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. > > Having carried out a few package-wide pieces of work I consider this a > disadvantage. Unmaintained code imposes a disproportionate burden when > trying to improve the rest of the codebase. > > I did suggest that we could test 3rd party packages in Travis. I think > that's a good idea anyway so we have a better idea of the impact of > changes on downstream users. We should try to avoid breaking > downstream projects but I don't think we should spend time improving > unmaintained code. Running integration tests on downstream dependencies is a good idea. Some people from other projects started working on some tooling for this, but I don't think it is completed yet. https://github.com/numba/texasbbq > > > Unfortunately, some of the projects that would have the most impact > > would also be the most difficult. For instance, certain improvements > > to the polys could have enormous impacts, but these require much > > deeper mathematics than most other projects, as well as familiarity > > with a large preexisting chunk of the codebase. > > Maybe we can break these down into more manageable pieces of work. We could definitely make some the ideas on the ideas page more approachable. A GSoC project for many of the ideas would necessarily only be some subset of the idea, with the full idea needing to be split across multiple summers' projects or work outside of GSoC. Another issue with some of these projects is that there aren't many people who can mentor them. Aaron Meurer > > -- > Oscar > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTL9NAOp0MqhLTLVcuU%3DRQdTGgAz-fQ7Q5dFVX_tbQdFQ%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6K9i7rJs4vca6a7QXF1CAeK6fCo%2BGqfRo6teFtNcbCk%3DQ%40mail.gmail.com.
