Skip to content

DEPS: make a package for the ci/code_checks.sh #27342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jreback opened this issue Jul 11, 2019 · 9 comments
Closed

DEPS: make a package for the ci/code_checks.sh #27342

jreback opened this issue Jul 11, 2019 · 9 comments
Assignees
Labels
Code Style Code style, linting, code_checks Enhancement Needs Discussion Requires discussion from core team before further action

Comments

@jreback
Copy link
Contributor

jreback commented Jul 11, 2019

I think it might be nice to put the ci/code_checks.sh into its own repo / library where others could use these.

I think we have quite sophisticated doc string validations, potentially these could migrate to numpydoc.

cc @datapythonista

@jreback jreback added the Dependencies Required and optional dependencies label Jul 11, 2019
@jreback jreback added this to the Contributions Welcome milestone Jul 11, 2019
@jorisvandenbossche
Copy link
Member

Unless there is a concrete demand, I think moving them to a separate repo will only be cumbersome. Because (IIUC) if you do a clean-up of some code + a change in the scripts, you need to do two PRs that need to be coordinated.

@WillAyd
Copy link
Member

WillAyd commented Jul 11, 2019

I would be a +1 on moving these out. Particularly with docstring validation it seems like a very strange thing to take on and maintain within pandas

@jbrockmendel
Copy link
Member

i agree with all three of you.

@jorisvandenbossche
Copy link
Member

i agree with all three of you.

Are you aware that I basically gave a -1 and Will a +1 ..? ;)

@datapythonista
Copy link
Member

I think in ci/code_checks.sh there is mainly the validation of the docstrings that it's worth considering. There are few more things, like the grep which fails when the text is found (grep does the opposite) or the sync between conda and pip deps, but I think they are too small to be worth a package.

I agree that the validation of docstrings should be in numpydoc, even if as Joris says this will come at an extra cost for us. But I'd say our validation starts to be quite mature, and I don't expect important changes, may be just some new rules, and those could be implemented without much coordination I think.

But probably the issue should be more for the numpydoc repo. They need to make a decision whether they want to make their standards more strict. I thought that I asked that in the numpy distribution list a while ago, but it looks like I didn't. I'll propose it when I have time, and depending on their interest we can decide.

@datapythonista datapythonista self-assigned this Jul 11, 2019
@gfyoung
Copy link
Member

gfyoung commented Jul 12, 2019

As long as the checks remain configurable / overridable if put into numpydoc, I don't see why we don't externalize these scripts. They have been relatively stable for a bit now.

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Jul 15, 2019 via email

@datapythonista
Copy link
Member

I started the discussion in the numpydoc repo (there was already an issue about having a stricter standard), and also in numpy-discussion. Will post here any update.

@mroeschke mroeschke added Enhancement Needs Discussion Requires discussion from core team before further action Code Style Code style, linting, code_checks and removed Dependencies Required and optional dependencies labels Jul 10, 2021
@mroeschke mroeschke removed this from the Contributions Welcome milestone Oct 13, 2022
@jbrockmendel
Copy link
Member

Looks like part of this was done in #28822. Not much interest since then. I think this has served its purpose. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code Style Code style, linting, code_checks Enhancement Needs Discussion Requires discussion from core team before further action
Projects
None yet
Development

No branches or pull requests

8 participants