I think we should relax our stringent no dependency stance for pure python dependencies. Pure python dependency management is essentially solved now for the python ecosystem with the various package managers. This dependency would also be pulled into the sympy organization, so we will have just as much control to maintain it as code in sympy's codebase.
Francesco is a long time valued contributor and if he wants/needs matchpy to help him make sympy better, then we should enable him to do that. Putting up a wall here likely only creates frustration and demotivation. There is likely more value in unleashing Francesco's matchpy improvements to sympy than any devalue adding a dependency to sympy creates. Jason moorepants.info +01 530-601-9791 On Wed, Oct 6, 2021 at 9:38 AM Francesco Bonazzi <franz.bona...@gmail.com> wrote: > > > On Tuesday, October 5, 2021 at 2:07:06 p.m. UTC+2 Oscar wrote: > >> >> I agree that pattern matching is a crucial part of a CAS and should >> really be the core of SymPy. If I was redesigning SymPy from scratch then >> everything would be built on top of a pattern-matching engine and almost >> all of the logic from the myriad Basic subclasses would just be written as >> pattern rules. My equivalent of SymEngine would just be a C implementation >> of the pattern-matching engine rather than a repeat of the object-oriented >> design of SymPy. >> > > SymPy can still be modified in order to use a pattern matcher. > > Also, MatchPy has been partly translated into C++ inside the SymEngine > project: > > https://github.com/symengine/symengine/tree/329a04be017daff0362b9177da2ef5b7e5d605f7/symengine/utilities/matchpycpp > > >> >> I also agree that matchpy looks like a good implementation of >> pattern-matching and it makes sense for it to be usable with SymPy. What >> the SymPEP does not address though is what benefit is gained for users by >> making matchpy a non-optional dependency. The examples shown look like >> somewhat specialised usage for which an interested user could just choose >> to install matchpy. >> > > The benefits are mostly for SymPy development. You can start defining > replacement rules to implement new algorithms. > > >> RUBI would be a good motivation but as far as I can tell RUBI does not >> yet work. Actually I would prefer it if RUBI was already in a separate >> package from SymPy - it should not have been merged until it was at least >> partially working. The rubi_tests folder is included for all users and >> includes e.g. the sympy/integrals/rubi/rubi_tests/tests/test_trinomials.py >> file which wastes at least 1.5MB disk space for every single SymPy user for >> precisely zero benefit (these tests should clearly be in a separate repo). >> I don't see how making matchpy a non-optional dependency would make it any >> easier to improve RUBI since anyone who wants to work on it can just >> install matchpy. In fact if RUBI was not in the main SymPy repo then it >> could have a hard dependency on matchpy. >> > > This can be done. > > >> The cost of making matchpy a non-optional dependency would be felt by >> downstream distributors of SymPy who would then have an additional >> dependency to include. It would also be felt by all users of SymPy with >> longer install time, more disk space etc. If a user does not use any of >> it's features then this cost comes with no benefit. >> > > Consider that it's pretty common now for libraries to depend on other > libraries. An alternative would be to copy the MatchPy project as a > subfolder inside SymPy (as it has been done for the *multipledispatch* > module). > > >> I am not saying this to disagree with the proposal but that there needs >> to be a clear rationale for making matchpy a hard dependency and the SymPEP >> does not address this at all. The SymPEP should also clearly spell out what >> the downsides of the proposal are. >> > > The major downside is probably that MatchPy has not been extensively > tested with SymPy. There is a risk factor in relying on a new library. > > -- > 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/003f5fd9-8137-40eb-a8a6-ca2378a08ccan%40googlegroups.com > <https://groups.google.com/d/msgid/sympy/003f5fd9-8137-40eb-a8a6-ca2378a08ccan%40googlegroups.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/CAP7f1AhfqzVwWoqbZosP_uXoM%2BJkw9z5LuvAtXKi0feb5zg8vQ%40mail.gmail.com.
