Use Ruff to do import sorting

[shwina]

Sort imports using Ruff (invoking ruff linter will now sort imports in addition to existing linting).

It looks like so far, imports have been kept sorted by manual invocations of ruff (or isort). This PR makes it so that the existing pre-commit hook will also take care of sorting imports.

This PR is based on the feedback/discussion in NVIDIA/cccl#3230.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ksimpson-work]

I do not experience this bahaviour (the automatic pre-commit ruff linting does sort my imports).

(cuda_py) ksimpson@NV-3KWHSV3:~/dev/cuda-python/cuda_core$ git commit -m 'test'
ruff.....................................................................Failed

• hook id: ruff
• files were modified by this hook

Fixed 1 error:

• cuda_core/tests/test_linker.py:
  1 × I001 (unsorted-imports)

Found 1 error (1 fixed, 0 remaining).

ruff-format..............................................................Passed

[shwina]

I do not experience this bahaviour (the automatic pre-commit ruff linting does sort my imports).

To clarify, what was the expected behaviour here? (i.e., which file had unsorted imports?)

[ksimpson-work]

I just moved an "import pytest" after the cuda core experiemental imports in test_linker.py to observe that ruff would resort it after the commit

[shwina]

I just moved an "import pytest" after the cuda core experiemental imports in test_linker.py to observe that ruff would resort it after the commit

From the output, it looks like indeed ruff did sort it back to correct order:

Fixed 1 error:

cuda_core/tests/test_linker.py:
1 × I001 (unsorted-imports)

was that not actually the case?

[ksimpson-work]

I might not correctly follow what you described above. My understanding is that when you make a commit, you are finding that ruff does not sort imports unless ytou trigger it manually. Is that correct?

[shwina]

Oh, I see - you are doing all this on main?

[ksimpson-work]

yes this is on main

[shwina]

Understood - yeah you're absolutely right. It looks like ruff has already been configured to sort imports on main.

Apologies, I assumed this wasn't the case based on Leo's comment here.

--

I think perhaps I misunderstood Leo's ask, which may be about using a top-level pyproject.toml specifying the ruff config, that both cuda.core and cuda.bindings can inherit (same as we are doing in CCCL). @leofang could you confirm?

[ksimpson-work]

No need to apologize! Thanks for looking into it. Let's see what leo says.

[leofang]

Thanks, guys! Sorry for my late reply...

I think perhaps I misunderstood Leo's ask, which may be about using a top-level pyproject.toml specifying the ruff config, that both cuda.core and cuda.bindings can inherit (same as we are doing in CCCL). @leofang could you confirm?

Yes. What I had in mind was:

1. Have a root pyproject.toml that's inherited by all of our namespace packages
2. Gradually sync up all Python configs across the two repos (cuda-python & cccl), starting with Ruff but eventually we want to cover everything (ex: mypy CI: Enforce type checks #312).

WDYT?

[leofang]

copied from CCCL root toml:

Suggested change

	target-version = "py310"
	target-version = "py310"
	fix = true
	show-fixes = true

[leofang]

Not sure if this is how it works? My intention is to spell out the old and new layouts:

Suggested change

	known-first-party = ["cuda.parallel"]
	known-first-party = ["cuda.cuda", "cuda.cudart", "cuda.nvrtc", "cuda.bindings"]

[leofang]

Another question: This PR does not generate any diff that touches the code? Asking because previously @vzhurba01 had some requirements for how cuda.bindings should be formatted (for example, we should not format code that's autogenerated), and we'd like to preserve the requirements during code review (or, even better, through automated tools).