Skip to content
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

Update CI to test python -m ruff on release #4397

Merged
merged 1 commit into from
May 12, 2023

Conversation

zanieb
Copy link
Member

@zanieb zanieb commented May 12, 2023

To prevent future regressions like #4394

@charliermarsh
Copy link
Member

Thank you, great idea.

@charliermarsh
Copy link
Member

Hopefully CI actually fails here? :)

@zanieb
Copy link
Member Author

zanieb commented May 12, 2023

@charliermarsh I only updated the release workflow. I think we'll need to add a new CI workflow for testing Python package builds if you want coverage per pull request (which is a great idea too).

@charliermarsh
Copy link
Member

Oh right right. Thanks.

@charliermarsh charliermarsh enabled auto-merge (squash) May 12, 2023 18:47
@charliermarsh charliermarsh merged commit ebda9b3 into astral-sh:main May 12, 2023
12 checks passed
@github-actions
Copy link
Contributor

github-actions bot commented May 12, 2023

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.00     17.4±0.67ms     2.3 MB/sec    1.05     18.3±0.64ms     2.2 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.02      4.3±0.15ms     3.9 MB/sec    1.00      4.2±0.18ms     3.9 MB/sec
linter/all-rules/numpy/globals.py          1.00   531.3±23.60µs     5.6 MB/sec    1.01   535.6±29.24µs     5.5 MB/sec
linter/all-rules/pydantic/types.py         1.00      7.4±0.31ms     3.5 MB/sec    1.02      7.5±0.42ms     3.4 MB/sec
linter/default-rules/large/dataset.py      1.00      8.5±0.22ms     4.8 MB/sec    1.02      8.6±0.25ms     4.7 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.02  1870.3±64.37µs     8.9 MB/sec    1.00  1829.6±58.64µs     9.1 MB/sec
linter/default-rules/numpy/globals.py      1.00   214.7±11.42µs    13.7 MB/sec    1.03   221.8±15.51µs    13.3 MB/sec
linter/default-rules/pydantic/types.py     1.00      3.9±0.33ms     6.5 MB/sec    1.00      3.9±0.24ms     6.5 MB/sec
parser/large/dataset.py                    1.02      7.0±0.21ms     5.8 MB/sec    1.00      6.9±0.19ms     5.9 MB/sec
parser/numpy/ctypeslib.py                  1.00  1377.3±56.02µs    12.1 MB/sec    1.00  1375.9±44.07µs    12.1 MB/sec
parser/numpy/globals.py                    1.00    134.7±6.87µs    21.9 MB/sec    1.02   136.8±10.10µs    21.6 MB/sec
parser/pydantic/types.py                   1.00      3.0±0.11ms     8.6 MB/sec    1.04      3.1±0.11ms     8.3 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.01     16.9±0.49ms     2.4 MB/sec    1.00     16.7±0.44ms     2.4 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      4.3±0.18ms     3.9 MB/sec    1.00      4.3±0.20ms     3.9 MB/sec
linter/all-rules/numpy/globals.py          1.00   497.4±23.13µs     5.9 MB/sec    1.02   508.0±21.05µs     5.8 MB/sec
linter/all-rules/pydantic/types.py         1.00      7.0±0.19ms     3.6 MB/sec    1.00      7.0±0.21ms     3.6 MB/sec
linter/default-rules/large/dataset.py      1.00      8.4±0.23ms     4.9 MB/sec    1.02      8.5±0.28ms     4.8 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.01  1778.5±99.64µs     9.4 MB/sec    1.00  1765.3±55.27µs     9.4 MB/sec
linter/default-rules/numpy/globals.py      1.00    192.1±4.33µs    15.4 MB/sec    1.04    199.0±7.69µs    14.8 MB/sec
linter/default-rules/pydantic/types.py     1.00      3.7±0.09ms     6.9 MB/sec    1.01      3.7±0.12ms     6.8 MB/sec
parser/large/dataset.py                    1.00      6.8±0.18ms     5.9 MB/sec    1.01      6.9±0.11ms     5.9 MB/sec
parser/numpy/ctypeslib.py                  1.02  1316.8±47.90µs    12.6 MB/sec    1.00  1296.5±34.73µs    12.8 MB/sec
parser/numpy/globals.py                    1.02    135.2±9.07µs    21.8 MB/sec    1.00    132.0±3.83µs    22.4 MB/sec
parser/pydantic/types.py                   1.03      3.0±0.12ms     8.5 MB/sec    1.00      2.9±0.07ms     8.8 MB/sec

@konstin
Copy link
Member

konstin commented May 12, 2023

thanks!

konstin added a commit to PyO3/maturin that referenced this pull request May 12, 2023
Warns when the user explicitly set `python-source` but that folder doesn't contain a python module.

This came up in ruff (astral-sh/ruff#4397, astral-sh/ruff#4399), where the crate name is `ruff_cli` and i didn't realize this takes precedence as module name over the package name.

The extra boolean isn't pretty but i wanted to avoid refactoring the entire method just for that.
konstin added a commit to PyO3/maturin that referenced this pull request May 12, 2023
…name` over Cargo.toml `package.name`.

I propose to change the precedence for determining the module name to consider before pyproject.toml `project.name` over Cargo.toml `package.name`. This came up in ruff (astral-sh/ruff#4397, astral-sh/ruff#4399), where the crate name is `ruff_cli` and the project name is `ruff`.

I'm not sure if there are any cases a user would like the crate name over the package name.
konstin added a commit to PyO3/maturin that referenced this pull request May 12, 2023
Warns when the user explicitly set `python-source` but that folder doesn't contain a python module.

This came up in ruff (astral-sh/ruff#4397, astral-sh/ruff#4399), where the crate name is `ruff_cli` and i didn't realize this takes precedence as module name over the package name.

The extra boolean isn't pretty but i wanted to avoid refactoring the entire method just for that.
konstin added a commit to PyO3/maturin that referenced this pull request May 13, 2023
Warns when the user explicitly set `python-source` but that folder doesn't contain a python module.

This came up in ruff (astral-sh/ruff#4397, astral-sh/ruff#4399), where the crate name is `ruff_cli` and i didn't realize this takes precedence as module name over the package name.

The extra boolean isn't pretty but i wanted to avoid refactoring the entire method just for that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants