On Fri, Mar 31, 2023 at 10:33 PM Jason Moore <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> > >> <[email protected]> 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 something different from just adding a pre-commit >> > >>> configuration that contributors can choose to use or not. The >> > >>> difference is that pre-commit.ci is a GitHub bot that will run the >> > >>> pre-commit hooks on all pull requests and can often fix the problems >> > >>> automatically by pushing a new commit to the PR. >> > >>> >> > >>> Currently if someone pushes a PR that has simple problems like >> > >>> trailing whitespace or unnecessary imports then the flake8 or quality >> > >>> checks in CI will report an error asking the contributor to fix those >> > >>> problems. With pre-commit.ci we could make it so that those problems >> > >>> are just fixed automatically without the contributor needing to do >> > >>> anything. >> > >>> >> > >>> Both trailing whitespace and unnecessary imports are automatically >> > >>> fixable e.g. there is already a bin/strip_whitespace script and ruff >> > >>> can fix the imports with: >> > >>> >> > >>> ruff check --select F401 --fix sympy >> > >>> >> > >>> Obviously other things could be fixed automatically but these are the >> > >>> two that I see most often where someone pushes and then needs to push >> > >>> a followup fixing commit after seeing CI checks fail. If precommit.ci >> > >>> was used there would be no need to push a follow up commit because the >> > >>> bot would just do it automatically. >> > >>> >> > >>> On the other hand if someone uses the pre-commit hook locally then >> > >>> that could fix these things automatically before pushing and there >> > >>> wouldn't be any need for the bot to fix them in CI. The advantage of >> > >>> the CI bot would be that it could apply simple fixes for someone who >> > >>> does not use the git hook and didn't check pre-commit before pushing. >> > >>> >> > >>> To be clear there would not be any requirement for any individual >> > >>> contributor to use pre-commit locally. However if pre-commit.ci runs >> > >>> on PRs then that is obviously not optional and there would be a bot >> > >>> pushing fix commits to PRs. >> > >>> >> > >>> Does anyone have any thoughts on enabling pre-commit.ci or otherwise >> > >>> encouraging contributors to use pre-commit? >> > >>> >> > >>> -- >> > >>> 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/CAHVvXxSmJ2aGsiHf6%2BNFLaBL0xkUeH0_CJ86uqQR-py6uCZnxg%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/CAP7f1Ah9-uRCPqpFWzbNLp_4z4gBSmQ6xmr0_aHPcuD78W6%3DZA%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%3D6%2BUYTFZWf%3DHJJZPx0UukKx1PgnTtY8%3DcK7MwJOTOmD1Tw%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/CAHVvXxR5CSvWrLEEgz827gPrQJj1soVWkOE%3Djo87FfxiOY_MkQ%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%3D6%2BNt8qRVCBY_MBQzW%3Dq1n2XgmZip4t_3V8f-kU1VcKMow%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/CAP7f1Ai6hthbys7cGx9UyXzVSEj%2BZQmx7KGx3SMdj2Sc4FSKWQ%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%3D6LAoT2gDGS1RNM677yUB%2B2wCaZj4jKohHd9HcmqcGt0jQ%40mail.gmail.com.
