enh(eic checklist): Suggested checklist items#360
Conversation
eliotwrobson
force-pushed
the
typechecking_suggestions
branch
from
733c7e0 to
e09b925
Compare
| - [ ] **Linting** The package uses automated linting (e.g., [ruff](https://docs.astral.sh/ruff/)) to enforce code style and quality standards, ideally integrated with CI. | ||
| - [ ] **Type checking** The package includes type hints and uses a type checker (e.g., [mypy](https://mypy-lang.org/)) to catch type-related issues, ideally integrated with CI. | ||
| - [ ] **Modern tooling** The package uses modern Python development tools (e.g., [uv](https://docs.astral.sh/uv/) for dependency management and virtual environments) to streamline development workflows. | ||
|
|
There was a problem hiding this comment.
Great to see linting and type checking requirements appearing optionally. Maybe a separate policy and a general timeline to move packages all packages over to requiring linting and type checks is in order?
The modern tooling part is very opinionated and we're leaning toward poetry in the package build guides from what I recall. So, I think this is going to be a bigger fish that'll take a while to reel in.
There was a problem hiding this comment.
Great to see linting and type checking requirements appearing optionally. Maybe a separate policy and a general timeline to move packages all packages over to requiring linting and type checks is in order?
I think a linting policy is reasonable but a type checking one would be too much, some packages have significant obstacles to doing this.
The modern tooling part is very opinionated and we're leaning toward
poetryin the package build guides from what I recall. So, I think this is going to be a bigger fish that'll take a while to reel in.
Likewise, especially since uv has taken over as a popular tool. This section is included mainly to reduce the number of rounds of feedback to newly submitted packages. It might be better to point people to a page discussing this in more detail since the issue is more nuanced than for the other tools.
There was a problem hiding this comment.
We are currently suggesting people use Hatch. UV is NOT yet a full end-to-end packaging tool. although it supports dep management and is so fast. We are recommending uv+ hatch right now. i've updated this but also noting that our build page needs an update to include uv as uv CAN build packages! you will just be using other tools if you want to create taskrunner like workflows (which both hatch and nox support).
Co-authored-by: James J Balamuta <coatless@users.noreply.github.com>
lwasser
left a comment
lwasser
left a comment
There was a problem hiding this comment.
@eliotwrobson i think we can merge this one as well. We may just want to consider updating the packaging guide with better UV integration.
right now we only focus on packaging end-to-end tools but uv fits on this page too.
Co-authored-by: Leah Wasser <leah@pyopensci.org>
3 participants
Add optional items to the EiC checklist. These items are recommended to reduce the rounds of feedback given to packages before full review starts, though not necessary as they may be prohibitively difficult to implement for some packages. Closes #329.