On Wed, Oct 6, 2021 at 1:52 AM Jason Moore <moorepa...@gmail.com> wrote: > > 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.
There's more cost to adding a dependency than just the installation questions, which I agree are not that big of an issue like they used to be. In fact we already have had mpmath as a dependency for a while, and it's proven to be just fine. The sorts of questions we need to ask when adding a hard dependency are - Who maintains the dependency? - What happens if they stop maintaining it? What is the risk level of that happening? - Does the package have a healthy codebase? For example, does the package use idiomatic Python? Does it have tests? Does it have documentation? - Does the package have a healthy community? For example, does it have a contributor guide? Does it have a code of conduct (and is it actually followed by the community)? Are active contributors regularly granted push access to the project? - With the above points, keep in mind that we would almost certainly have to upstream bug fixes at various points. How easy will that be to do? - How active is the development on the project? If it's not active, is that because there aren't many active maintainers or because the project has stabilized? if it is very active, is it stable, e.g., are there many API breaks? - Are there other large projects that also depend on this dependency? - What is the license of the dependency? Would the maintainers ever change this license to a more restrictive one? (We should not have hard dependencies that have more restrictive licenses than SymPy itself). - What are the tradeoffs of having the dependency vs. not having it? "Not having it" includes the option of writing the desired functionality directly in SymPy. - If we decide that the package no longer is suitable to be a dependency for one of the above reasons, what would our options be? - What are the recursive dependencies of the dependency, and how do the above questions apply to those? I like this blog post by Russ Cox, which outlines some of these same concerns. https://research.swtch.com/deps Any one of these could represent a reason for not including a package as a hard dependency. I've seen a lot of projects not really consider the above issues very carefully and end up being bitten by them. Consider, just as an example, the pymc project, which depended on theano, and was forced to maintain a new fork of it when the theano developers stopped maintaining it. These are the sorts of things I would like to formalize so that we always make sure to think about them. Just to be clear, I'm not saying that these things are all bad for matchpy, nor am I saying that we shouldn't add matchpy as a dependency. I just want to make sure we actually consider these things. Personally, when it comes to matchpy, I am most concerned about the size of the maintainer pool, since it only appears to have one or two active maintainers, which are part of an academic lab, which implies that they would likely stop maintaining it once they leave the lab. These are the sorts of concerns that should be addressed in the SymPEP, and weighed if they are worth it. > > 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. I also don't like unnecessary friction, which is why I felt for a long time that formal processes like SymPEP weren't necessary for SymPy. But we need to also consider SymPy's user base. The more people and upstream projects that are using SymPy, the more we can't just "move fast and break things". Significant changes should be made with care. If they aren't, we will be forced to roll them back, meaning annyong backwards incompatibilities for users. Aaron Meurer > > 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. > > -- > 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. -- 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%3D6L6XzTcsXrXVrf5tCH5NAa3dxNObS5bME2YvnSJ2cPOVA%40mail.gmail.com.
