Re: [sympy] Enabling precommit.ci to fix common PR problems automatically
On Fri, Mar 31, 2023 at 10:33 PM Jason Moore wrote: > > When the # of dependencies is large, dependabot is a very annoying feature. I > contributed to a Javascript lib and the dependabot floods your inbox and > notifications with useless PRs. It may be ok for us, since it is only > checking a handful of dependencies and those don't change too often. We actually have quite a few, assuming we were to pin all of them https://github.com/sympy/sympy/blob/master/.github/workflows/runtests.yml#L201-L203 (there's a few others in this file too, search for "install") https://github.com/sympy/sympy/blob/master/doc/requirements.txt I don't know if there's a tool that lets you easily see how often these are updated but my guess would be 1-5 updates a week. Aaron Meurer > > Jason > moorepants.info > +01 530-601-9791 > > > On Fri, Mar 31, 2023 at 10:44 PM Aaron Meurer wrote: >> >> I only ever hear bad things about dependabot. I don't have any >> experience with it myself, but I would be cautious about using it. >> Maybe try reaching out to other communities that have tried it to see >> what their experiences have been. >> >> Aaron Meurer >> >> On Fri, Mar 31, 2023 at 8:20 AM Oscar Benjamin >> wrote: >> > >> > Okay, so it seems people are not keen on integrating the pre-commit.ci bot. >> > >> > We can of course continue to make a pre-commit config that any >> > contributor wants to use. >> > >> > Another question I have is what people think about using dependabot. >> > We regularly have problems where new versions of SymPy's dependencies >> > cause breakage in CI. This can happen because of things like: >> > >> > - New Sphinx versions. Basically every significant release of Sphinx >> > seems to break some part of building SymPy's docs. >> > - New numpy/scipy etc versions. It is common that these will introduce >> > things like deprecation warnings and also various things will break >> > because of the removal of functions etc. >> > - New versions of linters like flake8 and its plugins or mypy. >> > >> > Whenever this happens and CI gets broken it is both disruptive and >> > confusing for any contributors whose PRs will fail CI checks because >> > of problems that are unrelated to the changes they have made. >> > >> > A common way to prevent CI from breaking is to pin dependencies of the >> > things that are used in CI but the difficulty with that is the need to >> > keep the pinned versions updated as new releases are made. A widely >> > used solution for this is dependabot which is a bot that can >> > automatically open PRs to update pinned versions. Depending on how >> > many versions are pinned and how often the pinned things make new >> > releases there would be some number of PRs from dependabot updating >> > versions one dependency at a time (dependabot does not have a way to >> > do several dependencies in a single PR). >> > >> > The advantage of using dependabot is that if a new version of some >> > dependency causes CI to break then it will only break in dependabot's >> > PR that tries to bring in the update. Otherwise we can keep things >> > updated by updating the versions only when CI passes. >> > >> > The dependabot update PRs can be annoying but at the same time they >> > are very simple PRs that are easy to review and merge if CI passes. >> > When CI fails they would often also be easy problems to fix and would >> > often make suitable "easy to fix" issues (we can afford to do this if >> > there is no need to rush in a fix because of broken CI). >> > >> > Does anyone have any views on enabling dependabot on the SymPy repo >> > (or some similar alternative)? >> > >> > -- >> > Oscar >> > >> > On Tue, 28 Mar 2023 at 22:53, Aaron Meurer wrote: >> > > >> > > That's what I was worried about too. If the bot pushes a commit, then >> > > the PR author won't be able to push any additional commits unless they >> > > either pull first or force push. Personally I would find that a little >> > > surprising, and might not even notice it when I do "git push". Plus I >> > > feel like this would push people into the bad habit of always force >> > > pushing. >> > > >> > > Aaron Meurer >> > > >> > > On Tue, Mar 28, 2023 at 9:50 AM Jason Moore wrote: >> > >> >> > >> I personally would find a bot adding commits to my work a bit >> > >> intrusive. If the bot posted a comment to the issue telling me what to >> > >> fix, that would be preferable. Right now we have to make a few clicks >> > >> to see why the linter failed. >> > >> >> > >> Conda forge has a bot that will add commits to your branch, but only if >> > >> you explicitly ask it to. If we had some bot commands like '@sympy/bot >> > >> please fix flake8 issues' then that would run the fix and add the >> > >> commit, but it is the author's choice to do so. >> > >> >> > >> Jason >> > >> moorepants.info >> > >> +01 530-601-9791 >> > >> >> > >> >> > >> On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin >> > >> wrote: >> > >>> >> > >>> Hi all, >> > >>> >>
Re: [sympy] Enabling precommit.ci to fix common PR problems automatically
When the # of dependencies is large, dependabot is a very annoying feature. I contributed to a Javascript lib and the dependabot floods your inbox and notifications with useless PRs. It may be ok for us, since it is only checking a handful of dependencies and those don't change too often. Jason moorepants.info +01 530-601-9791 On Fri, Mar 31, 2023 at 10:44 PM Aaron Meurer wrote: > I only ever hear bad things about dependabot. I don't have any > experience with it myself, but I would be cautious about using it. > Maybe try reaching out to other communities that have tried it to see > what their experiences have been. > > Aaron Meurer > > On Fri, Mar 31, 2023 at 8:20 AM Oscar Benjamin > wrote: > > > > Okay, so it seems people are not keen on integrating the pre-commit.ci > bot. > > > > We can of course continue to make a pre-commit config that any > > contributor wants to use. > > > > Another question I have is what people think about using dependabot. > > We regularly have problems where new versions of SymPy's dependencies > > cause breakage in CI. This can happen because of things like: > > > > - New Sphinx versions. Basically every significant release of Sphinx > > seems to break some part of building SymPy's docs. > > - New numpy/scipy etc versions. It is common that these will introduce > > things like deprecation warnings and also various things will break > > because of the removal of functions etc. > > - New versions of linters like flake8 and its plugins or mypy. > > > > Whenever this happens and CI gets broken it is both disruptive and > > confusing for any contributors whose PRs will fail CI checks because > > of problems that are unrelated to the changes they have made. > > > > A common way to prevent CI from breaking is to pin dependencies of the > > things that are used in CI but the difficulty with that is the need to > > keep the pinned versions updated as new releases are made. A widely > > used solution for this is dependabot which is a bot that can > > automatically open PRs to update pinned versions. Depending on how > > many versions are pinned and how often the pinned things make new > > releases there would be some number of PRs from dependabot updating > > versions one dependency at a time (dependabot does not have a way to > > do several dependencies in a single PR). > > > > The advantage of using dependabot is that if a new version of some > > dependency causes CI to break then it will only break in dependabot's > > PR that tries to bring in the update. Otherwise we can keep things > > updated by updating the versions only when CI passes. > > > > The dependabot update PRs can be annoying but at the same time they > > are very simple PRs that are easy to review and merge if CI passes. > > When CI fails they would often also be easy problems to fix and would > > often make suitable "easy to fix" issues (we can afford to do this if > > there is no need to rush in a fix because of broken CI). > > > > Does anyone have any views on enabling dependabot on the SymPy repo > > (or some similar alternative)? > > > > -- > > Oscar > > > > On Tue, 28 Mar 2023 at 22:53, Aaron Meurer wrote: > > > > > > That's what I was worried about too. If the bot pushes a commit, then > the PR author won't be able to push any additional commits unless they > either pull first or force push. Personally I would find that a little > surprising, and might not even notice it when I do "git push". Plus I feel > like this would push people into the bad habit of always force pushing. > > > > > > Aaron Meurer > > > > > > On Tue, Mar 28, 2023 at 9:50 AM Jason Moore > wrote: > > >> > > >> I personally would find a bot adding commits to my work a bit > intrusive. If the bot posted a comment to the issue telling me what to fix, > that would be preferable. Right now we have to make a few clicks to see why > the linter failed. > > >> > > >> Conda forge has a bot that will add commits to your branch, but only > if you explicitly ask it to. If we had some bot commands like '@sympy/bot > please fix flake8 issues' then that would run the fix and add the commit, > but it is the author's choice to do so. > > >> > > >> Jason > > >> moorepants.info > > >> +01 530-601-9791 > > >> > > >> > > >> On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > > >>> > > >>> Hi all, > > >>> > > >>> There are two open PRs discussing the potential use of pre-commit and > > >>> pre-commit.ci in SymPy: > > >>> > > >>> https://github.com/sympy/sympy/pull/24908 > > >>> https://github.com/sympy/sympy/pull/24941 > > >>> > > >>> I want to know what others think specifically about enabling > > >>> pre-commit.ci on the sympy repo or otherwise encouraging use of > > >>> pre-commit for contributors. > > >>> > > >>> I'll explain below but you can also read about pre-commit and > > >>> pre-commit.ci here: > > >>> > > >>> https://pre-commit.com/ > > >>> https://pre-commit.ci/ > > >>> > > >>> The pre-commit tool is
Re: [sympy] Re: ChatGPT and SymPy
The only way you always guarantee get right answer is to provide the ChatGPT two correct knowledge, but ask it to pick the better one. For solving the math problems, I think that these sort of encoding may be helpful. On Friday, March 31, 2023 at 7:23:41 AM UTC+9 asme...@gmail.com wrote: > It's the same as the example I showed above. It basically can't do math > (or really, it can't even do arithmetic). It seems to have an especially > hard time with fractions. > > I asked it to generate code using Python to compute the norm or [1/2, 1, > 1]. It was able to generate accurate code using pure Python, NumPy, and > SymPy to compute the norm. In each case it also confidently claimed the > output would be something wrong like 1.5811388300841898 or sqrt(3)/2, but > if you actually copy and run the code it gives the correct result. My only > gripe with the code it generated is it unnecessarily used CoordSys3D when > it could just use Matrix.norm, although that's just random and if you ask > it the same thing it might not do that. > > Aaron Meurer > > On Thu, Mar 30, 2023 at 4:03 PM Chris Smith wrote: > >> Use with caution -- the set-up can be right and the answer wrong as in: >> >> What is the norm of vector (1/2, 1, 1)? >> >> The norm of a vector is defined as the length or magnitude of the vector. >> The norm of a vector v = (v1, v2, ..., vn) is given by the formula: >> >> ||v|| = sqrt(v1^2 + v2^2 + ... + vn^2) >> >> So, for the vector (1/2, 1, 1), the norm is: >> >> || (1/2, 1, 1) || = sqrt( (1/2)^2 + 1^2 + 1^2 ) = sqrt( 1/4 + 1 + 1 ) = >> sqrt( 6.25 ) = 2.5 >> >> Therefore, the norm of the vector (1/2, 1, 1) is 2.5. >> The answer: `assert sqrt(sum([i**2 for i in (1/2,1,1)])) == 1.5` >> On Wednesday, March 29, 2023 at 7:48:48 AM UTC-5 e...@tssfl.co wrote: >> >>> ChatGPT is quite impressive! For those who do not have access to ChatGPT >>> and/or Python, can use it with SageCell at >>> https://tssfl.com/viewtopic.php?t=6651 >>> >>> SageCell supports countless Python libraries including SymPy. >>> >>> I tested ChatGPT with a number of examples, it tries solve even complex >>> maths problems, e.g., : >>> >>> Example 1: >>> >>> Find a 4x4 matrix which is a Jordan canonical form of the matrix A = >>> matrix([[5, -1, 0, 0],[9, -1, 0, 0],[0, 0, 7, -2], [0, 0, 12, -3]]). >>> >>> assistant: >>> >>> To find the Jordan canonical form of a matrix, we need to find the >>> eigenvalues and eigenvectors, and then use them to construct the Jordan >>> blocks. >>> >>> First, we find the eigenvalues of A by solving for the determinant of (A - >>> lambda*I), where I is the identity matrix: >>> >>> |5 - lambda -1 0 0 | >>> |9-1 - lambda 0 0 | >>> |0 0 7 - lambda -2 | >>> |0 0 12 -3 - lambda| >>> >>> = (5 - lambda)(-1 - lambda)(7 - lambda)(-3 - lambda) - 9*(-1)*(7 - >>> lambda)*(12) >>> = lambda^4 - 8*lambda^3 + 11*lambda^2 + 38*lambda - 360 >>> = (lambda - 10)(lambda - 5)(lambda + 3)(lambda - 4) >>> >>> Therefore, the eigenvalues are: lambda1 = 10, lambda2 = 5, lambda3 = -3, >>> lambda4 = 4. >>> >>> Next, we find the eigenvectors corresponding to each eigenvalue. For >>> lambda1 = 10, we solve (A - 10*I)x = 0: >>> >>> | -5 -1 00 | >>> | 9 -11 00 | >>> | 0 0 -3-2 | >>> | 0 0 12 -13 | >>> >>> By performing elementary row operations to reduce this matrix, we obtain: >>> >>> | 1 0 01 | >>> | 0 1 0 3/2 | >>> | 0 0 12 | >>> | 0 0 00 | >>> >>> So the eigenvector corresponding to lambda1 is x1 = [1, -3/2, -2, 1]. >>> >>> Similarly, for lambda2 = 5, we solve (A - 5*I)x = 0: >>> >>> | 0 -1 00 | >>> | 9 -6 00 | >>> | 0 0 2 -2 | >>> | 0 0 12 -8 | >>> >>> By performing elementary row operations to reduce this matrix, we obtain: >>> >>> | 1 -3 0 0 | >>> | 0 0 1 -1 | >>> | 0 0 0 0 | >>> | 0 0 0 0 | >>> >>> So the eigenvector corresponding to lambda2 is x2 = [3, 1, 0, 0]. >>> >>> For lambda3 = -3, we solve (A + 3*I)x = 0: >>> >>> | 8 -1 00 | >>> | 9 -2 00 | >>> | 0 0 4 -2 | >>> | 0 0 12 -6 | >>> >>> By performing elementary row operations to reduce this matrix, we obtain: >>> >>> | 1 -1/2 0 0 | >>> | 0 0 1 -1/2 | >>> | 0 0 0 0| >>> | 0 0 0 0| >>> >>> So the eigenvector corresponding to lambda3 is x3 = [1/2, 1, 1/2, 0]. >>> >>> Finally, for lambda4 = 4, we solve (A - 4*I)x = 0: >>> >>> | 1 -1 00 | >>> | 9 -5 00 | >>> | 0 0 3 -2 | >>> | 0 0 12 -7 | >>> >>> By performing elementary row operations to reduce this matrix, we obtain: >>> >>> | 1 -1 00 | >>> | 0 0 1 -2/3 | >>> | 0 0 00| >>> | 0 0 00| >>> >>> So the eigenvector corresponding to lambda4 is x4 = [1, 1/3, 0, 0]. >>> >>> We can now construct the Jordan canonical form of
Re: [sympy] GSoC2023 Introduction
On Fri, Mar 31, 2023 at 8:05 AM Pedro Xavier wrote: > > Hello everyone from the community, > > My name is Pedro, I'm a fourth year control engineering student in France and > I'm studying the ideas for my application. I thought I should introduce > myself in here since I hope we'll be working together during the summer and > beyond. > > I'd also like to use this opportunity to better understand the format of the > program itself. Although I've read through the instructions and the FAQ, here > are some questions whose answers I either missed or couldn't find: > > 1. Can more than one proposal regarding the same project be accepted? > Parsing through the ideas page, I've selected a few that have caught my eye. > These ideas in particular seemed to be a better fit for my profile and are > some things I'd be interested in working on. I also remember seeing them > being discussed by peers in the forum and thus the question arose: are these > submissions mutually exclusive? That is, is a single proposal for each idea > going to be selected? Yes, this can happen. In that case we will generally work with the applicants to make sure the work is separate from each other. Many of the projects listed on the ideas page have quite a bit of work that needs to be done on them so there is definitely enough there for multiple projects. > > 2. Can I include multiple goals form different topics as to what I want to > achieve? > For example, could I say that I'd like to both work on the control package > and to fix bugs in the classic mechanics packages? Would that affect the > quality of my proposal? You should focus on a single project. Of course many projects will involve working on code from different modules, but it's best if your proposal focuses on a single coherent goal. Aaron Meurer > > -- > 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/8d7329f4-2da1-4c18-807c-396a6c66c6c3n%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/CAKgW%3D6Kv81wbJj%2BpOiDnaMW2WamcxwabDAG%3DsmNWgVK9BoZjMQ%40mail.gmail.com.
Re: [sympy] Enabling precommit.ci to fix common PR problems automatically
I only ever hear bad things about dependabot. I don't have any experience with it myself, but I would be cautious about using it. Maybe try reaching out to other communities that have tried it to see what their experiences have been. Aaron Meurer On Fri, Mar 31, 2023 at 8:20 AM Oscar Benjamin wrote: > > Okay, so it seems people are not keen on integrating the pre-commit.ci bot. > > We can of course continue to make a pre-commit config that any > contributor wants to use. > > Another question I have is what people think about using dependabot. > We regularly have problems where new versions of SymPy's dependencies > cause breakage in CI. This can happen because of things like: > > - New Sphinx versions. Basically every significant release of Sphinx > seems to break some part of building SymPy's docs. > - New numpy/scipy etc versions. It is common that these will introduce > things like deprecation warnings and also various things will break > because of the removal of functions etc. > - New versions of linters like flake8 and its plugins or mypy. > > Whenever this happens and CI gets broken it is both disruptive and > confusing for any contributors whose PRs will fail CI checks because > of problems that are unrelated to the changes they have made. > > A common way to prevent CI from breaking is to pin dependencies of the > things that are used in CI but the difficulty with that is the need to > keep the pinned versions updated as new releases are made. A widely > used solution for this is dependabot which is a bot that can > automatically open PRs to update pinned versions. Depending on how > many versions are pinned and how often the pinned things make new > releases there would be some number of PRs from dependabot updating > versions one dependency at a time (dependabot does not have a way to > do several dependencies in a single PR). > > The advantage of using dependabot is that if a new version of some > dependency causes CI to break then it will only break in dependabot's > PR that tries to bring in the update. Otherwise we can keep things > updated by updating the versions only when CI passes. > > The dependabot update PRs can be annoying but at the same time they > are very simple PRs that are easy to review and merge if CI passes. > When CI fails they would often also be easy problems to fix and would > often make suitable "easy to fix" issues (we can afford to do this if > there is no need to rush in a fix because of broken CI). > > Does anyone have any views on enabling dependabot on the SymPy repo > (or some similar alternative)? > > -- > Oscar > > On Tue, 28 Mar 2023 at 22:53, Aaron Meurer wrote: > > > > That's what I was worried about too. If the bot pushes a commit, then the > > PR author won't be able to push any additional commits unless they either > > pull first or force push. Personally I would find that a little surprising, > > and might not even notice it when I do "git push". Plus I feel like this > > would push people into the bad habit of always force pushing. > > > > Aaron Meurer > > > > On Tue, Mar 28, 2023 at 9:50 AM Jason Moore wrote: > >> > >> I personally would find a bot adding commits to my work a bit intrusive. > >> If the bot posted a comment to the issue telling me what to fix, that > >> would be preferable. Right now we have to make a few clicks to see why the > >> linter failed. > >> > >> Conda forge has a bot that will add commits to your branch, but only if > >> you explicitly ask it to. If we had some bot commands like '@sympy/bot > >> please fix flake8 issues' then that would run the fix and add the commit, > >> but it is the author's choice to do so. > >> > >> Jason > >> moorepants.info > >> +01 530-601-9791 > >> > >> > >> On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin > >> wrote: > >>> > >>> Hi all, > >>> > >>> There are two open PRs discussing the potential use of pre-commit and > >>> pre-commit.ci in SymPy: > >>> > >>> https://github.com/sympy/sympy/pull/24908 > >>> https://github.com/sympy/sympy/pull/24941 > >>> > >>> I want to know what others think specifically about enabling > >>> pre-commit.ci on the sympy repo or otherwise encouraging use of > >>> pre-commit for contributors. > >>> > >>> I'll explain below but you can also read about pre-commit and > >>> pre-commit.ci here: > >>> > >>> https://pre-commit.com/ > >>> https://pre-commit.ci/ > >>> > >>> The pre-commit tool is something that can be installed locally and can > >>> be used directly or as a git hook so that when making a git commit > >>> some quick checks can run on the code. The PR gh-24908 would add some > >>> configuration for this so that a contributor can either run some > >>> checks before committing or can install pre-commit as a git hook so > >>> that git commit automatically runs the checks. The configuration in > >>> gh-24908 means that pre-commit runs flake8 and ruff but specifically > >>> only on the files that are being changed in the commit which is > >>>
Re: [sympy] Enabling precommit.ci to fix common PR problems automatically
I like the idea of the following With https://github.com/sympy/sympy/pull/24908 you can pip install pre-commit and then any time you want to run the precommit checks you just run: $ pre-commit flake8...Passed ruff.Passed I especially like that they will only check changed files. /c On Friday, March 31, 2023 at 9:20:57 AM UTC-5 Oscar wrote: > Okay, so it seems people are not keen on integrating the pre-commit.ci > bot. > > We can of course continue to make a pre-commit config that any > contributor wants to use. > > Another question I have is what people think about using dependabot. > We regularly have problems where new versions of SymPy's dependencies > cause breakage in CI. This can happen because of things like: > > - New Sphinx versions. Basically every significant release of Sphinx > seems to break some part of building SymPy's docs. > - New numpy/scipy etc versions. It is common that these will introduce > things like deprecation warnings and also various things will break > because of the removal of functions etc. > - New versions of linters like flake8 and its plugins or mypy. > > Whenever this happens and CI gets broken it is both disruptive and > confusing for any contributors whose PRs will fail CI checks because > of problems that are unrelated to the changes they have made. > > A common way to prevent CI from breaking is to pin dependencies of the > things that are used in CI but the difficulty with that is the need to > keep the pinned versions updated as new releases are made. A widely > used solution for this is dependabot which is a bot that can > automatically open PRs to update pinned versions. Depending on how > many versions are pinned and how often the pinned things make new > releases there would be some number of PRs from dependabot updating > versions one dependency at a time (dependabot does not have a way to > do several dependencies in a single PR). > > The advantage of using dependabot is that if a new version of some > dependency causes CI to break then it will only break in dependabot's > PR that tries to bring in the update. Otherwise we can keep things > updated by updating the versions only when CI passes. > > The dependabot update PRs can be annoying but at the same time they > are very simple PRs that are easy to review and merge if CI passes. > When CI fails they would often also be easy problems to fix and would > often make suitable "easy to fix" issues (we can afford to do this if > there is no need to rush in a fix because of broken CI). > > Does anyone have any views on enabling dependabot on the SymPy repo > (or some similar alternative)? > > -- > Oscar > > On Tue, 28 Mar 2023 at 22:53, Aaron Meurer wrote: > > > > That's what I was worried about too. If the bot pushes a commit, then > the PR author won't be able to push any additional commits unless they > either pull first or force push. Personally I would find that a little > surprising, and might not even notice it when I do "git push". Plus I feel > like this would push people into the bad habit of always force pushing. > > > > Aaron Meurer > > > > On Tue, Mar 28, 2023 at 9:50 AM Jason Moore wrote: > >> > >> I personally would find a bot adding commits to my work a bit > intrusive. If the bot posted a comment to the issue telling me what to fix, > that would be preferable. Right now we have to make a few clicks to see why > the linter failed. > >> > >> Conda forge has a bot that will add commits to your branch, but only if > you explicitly ask it to. If we had some bot commands like '@sympy/bot > please fix flake8 issues' then that would run the fix and add the commit, > but it is the author's choice to do so. > >> > >> Jason > >> moorepants.info > >> +01 530-601-9791 <(530)%20601-9791> > >> > >> > >> On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin > wrote: > >>> > >>> Hi all, > >>> > >>> There are two open PRs discussing the potential use of pre-commit and > >>> pre-commit.ci in SymPy: > >>> > >>> https://github.com/sympy/sympy/pull/24908 > >>> https://github.com/sympy/sympy/pull/24941 > >>> > >>> I want to know what others think specifically about enabling > >>> pre-commit.ci on the sympy repo or otherwise encouraging use of > >>> pre-commit for contributors. > >>> > >>> I'll explain below but you can also read about pre-commit and > >>> pre-commit.ci here: > >>> > >>> https://pre-commit.com/ > >>> https://pre-commit.ci/ > >>> > >>> The pre-commit tool is something that can be installed locally and can > >>> be used directly or as a git hook so that when making a git commit > >>> some quick checks can run on the code. The PR gh-24908 would add some > >>> configuration for this so that a contributor can either run some > >>> checks before committing or can install pre-commit as a git hook so > >>> that git commit automatically runs the checks. The
Re: [sympy] Enabling precommit.ci to fix common PR problems automatically
Okay, so it seems people are not keen on integrating the pre-commit.ci bot. We can of course continue to make a pre-commit config that any contributor wants to use. Another question I have is what people think about using dependabot. We regularly have problems where new versions of SymPy's dependencies cause breakage in CI. This can happen because of things like: - New Sphinx versions. Basically every significant release of Sphinx seems to break some part of building SymPy's docs. - New numpy/scipy etc versions. It is common that these will introduce things like deprecation warnings and also various things will break because of the removal of functions etc. - New versions of linters like flake8 and its plugins or mypy. Whenever this happens and CI gets broken it is both disruptive and confusing for any contributors whose PRs will fail CI checks because of problems that are unrelated to the changes they have made. A common way to prevent CI from breaking is to pin dependencies of the things that are used in CI but the difficulty with that is the need to keep the pinned versions updated as new releases are made. A widely used solution for this is dependabot which is a bot that can automatically open PRs to update pinned versions. Depending on how many versions are pinned and how often the pinned things make new releases there would be some number of PRs from dependabot updating versions one dependency at a time (dependabot does not have a way to do several dependencies in a single PR). The advantage of using dependabot is that if a new version of some dependency causes CI to break then it will only break in dependabot's PR that tries to bring in the update. Otherwise we can keep things updated by updating the versions only when CI passes. The dependabot update PRs can be annoying but at the same time they are very simple PRs that are easy to review and merge if CI passes. When CI fails they would often also be easy problems to fix and would often make suitable "easy to fix" issues (we can afford to do this if there is no need to rush in a fix because of broken CI). Does anyone have any views on enabling dependabot on the SymPy repo (or some similar alternative)? -- Oscar On Tue, 28 Mar 2023 at 22:53, Aaron Meurer wrote: > > That's what I was worried about too. If the bot pushes a commit, then the PR > author won't be able to push any additional commits unless they either pull > first or force push. Personally I would find that a little surprising, and > might not even notice it when I do "git push". Plus I feel like this would > push people into the bad habit of always force pushing. > > Aaron Meurer > > On Tue, Mar 28, 2023 at 9:50 AM Jason Moore wrote: >> >> I personally would find a bot adding commits to my work a bit intrusive. If >> the bot posted a comment to the issue telling me what to fix, that would be >> preferable. Right now we have to make a few clicks to see why the linter >> failed. >> >> Conda forge has a bot that will add commits to your branch, but only if you >> explicitly ask it to. If we had some bot commands like '@sympy/bot please >> fix flake8 issues' then that would run the fix and add the commit, but it is >> the author's choice to do so. >> >> Jason >> moorepants.info >> +01 530-601-9791 >> >> >> On Tue, Mar 28, 2023 at 3:41 PM Oscar Benjamin >> wrote: >>> >>> Hi all, >>> >>> There are two open PRs discussing the potential use of pre-commit and >>> pre-commit.ci in SymPy: >>> >>> https://github.com/sympy/sympy/pull/24908 >>> https://github.com/sympy/sympy/pull/24941 >>> >>> I want to know what others think specifically about enabling >>> pre-commit.ci on the sympy repo or otherwise encouraging use of >>> pre-commit for contributors. >>> >>> I'll explain below but you can also read about pre-commit and >>> pre-commit.ci here: >>> >>> https://pre-commit.com/ >>> https://pre-commit.ci/ >>> >>> The pre-commit tool is something that can be installed locally and can >>> be used directly or as a git hook so that when making a git commit >>> some quick checks can run on the code. The PR gh-24908 would add some >>> configuration for this so that a contributor can either run some >>> checks before committing or can install pre-commit as a git hook so >>> that git commit automatically runs the checks. The configuration in >>> gh-24908 means that pre-commit runs flake8 and ruff but specifically >>> only on the files that are being changed in the commit which is >>> convenient because it is much faster than checking the whole codebase. >>> >>> To be clear adding the pre-commit config to the sympy repo does not >>> make it mandatory for all contributors to use the git hook. However it >>> could be something that is "recommended" as it will quickly show up >>> some common problems that would otherwise fail the checks in CI after >>> opening a PR or after pushing to a PR. >>> >>> What is also discussed in those PRs is adding pre-commit.ci to the >>> sympy repo which is
[sympy] GSoC2023 Introduction
Hello everyone from the community, My name is Pedro, I'm a fourth year control engineering student in France and I'm studying the ideas for my application. I thought I should introduce myself in here since I hope we'll be working together during the summer and beyond. I'd also like to use this opportunity to better understand the format of the program itself. Although I've read through the instructions and the FAQ, here are some questions whose answers I either missed or couldn't find: *1. Can more than one proposal regarding the same project be accepted? * Parsing through the ideas page, I've selected a few that have caught my eye. These ideas in particular seemed to be a better fit for my profile and are some things I'd be interested in working on. I also remember seeing them being discussed by peers in the forum and thus the question arose: are these submissions mutually exclusive? That is, is a single proposal for each idea going to be selected? *2. Can I include multiple goals form different topics as to what I want to achieve? * For example, could I say that I'd like to both work on the control package and to fix bugs in the classic mechanics packages? Would that affect the quality of my proposal? -- 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/8d7329f4-2da1-4c18-807c-396a6c66c6c3n%40googlegroups.com.
[sympy] Introduction and contribution in Stats module
Hello everyone, I am Pranav Agrawal and i am currently a second year student in International Institute of information technology, Hyderabad. I am very familiar with python and have made multiple projects in it for both course work and as hobby projects. I am fluent in topics like linear algebra and calculus, and am specially interested in probability and statistics. Looking at the GSoC ideas, i could not find any ideas related to the stats module. Hence i wanted to know if there are any open topics in the stats module for me to pursue. -- 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/49eaa8fa-fe79-4615-8c20-f0eb40c6579an%40googlegroups.com.
Re: [sympy] Improving Polynomial GCD proposal for GSoC 2023
Hi Abhishek, This is a nice looking proposal. I think what is proposed to do is over-ambitious though. I expect that it is not possible to make really good implementations of all of the algorithms listed within the time of a single GSOC project. In practice probably various other things will need to be implemented in stages just to get any one of the algorithms to work efficiently with the sparse implementations and this proposal seems to overlook that additional work that will become apparent when someone starts to work on this. Likewise integrating any algorithm so that it is used within existing codepaths always throws up unforeseen problems that will need to be handled. I don't think it is necessarily bad that the proposal is over ambitious because we can see what can be done in the available time. Probably the ordering of tasks should be changed though so we wouldn't want to implement all algorithms one by one and then only try to integrate them at the end. Doing it that way would mean probably not reaching the integration stage before time runs out. Instead we should add benchmarks, implement a single algorithm, integrate and optimise that algorithm and only then consider implementing another algorithm depending on how much time there is left. Oscar On Fri, 31 Mar 2023 at 10:27, ABHISHEK PATIDAR <2311abhip...@gmail.com> wrote: > > Hi there, > > I'm Abhishek Patidar. I am interested in working on the Improving Polynomial > GCDs project over the upcoming summer. I have attached a draft of my proposal > below and would appreciate your feedback on any discrepancies you may see in > my project vision. I am open to all feedback that can help me improve my > chances of being selected, including suggestions on timeline, strategy, and > objectives. > > Here is the link to my proposal: > https://drive.google.com/file/d/1Xlf72ABH68kb3BT8MISgH9MNIUej-lGo/view?usp=share_link > > Or on the wiki page: > https://github.com/sympy/sympy/wiki/GSoC-2023-Current-Applications > > Thanks and Regards, > Abhishek > > -- > 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/77528f98-d83d-48d3-8694-7f8dbb965348n%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/CAHVvXxQGerBwRyF1%3DOB-ErK_p8-szx2tKgZ7PC1Nwq-1sunAXA%40mail.gmail.com.
[sympy] Improving Polynomial GCD proposal for GSoC 2023
Hi there, I'm Abhishek Patidar. I am interested in working on the Improving Polynomial GCDs project over the upcoming summer. I have attached a draft of my proposal below and would appreciate your feedback on any discrepancies you may see in my project vision. I am open to all feedback that can help me improve my chances of being selected, including suggestions on timeline, strategy, and objectives. Here is the link to my proposal: https://drive.google.com/file/d/1Xlf72ABH68kb3BT8MISgH9MNIUej-lGo/view?usp=share_link Or on the wiki page: https://github.com/sympy/sympy/wiki/GSoC-2023-Current-Applications Thanks and Regards, Abhishek -- 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/77528f98-d83d-48d3-8694-7f8dbb965348n%40googlegroups.com.
