Development: Improve sandbox documentation for non-conda users

[amotl]

Hi again. This little documentation improvement was created along the lines of GH-483, as I am not using Anaconda, but plain Python. It's just a very minimal improvement to also help others approaching the development sandbox.

[martindurant]

If you are interested, the flake8 setup should really be included as a precommit hook as with other repos. Also, the supported python versions are out of date.

[amotl]

Hi Martin. This patch focused on bringing in just a little improvement to set up a sandbox to invoke the software test cases. In a similar spirit, GH-483 focused on other matters.

The flake8 setup should really be included as a precommit hook as with other repos. Also, the supported Python versions are out of date.

It's probably true, but I didn't focus on those concerns with this patch. Do you prefer to receive PRs which touch all modernization aspects at once, to make CI succeed after a maintenance hiatus? In this case, we'd probably need to bundle more concerns into the same PR. I can easily do it, I just wanted to start humble and ask for relevant guidance beforehand.

[martindurant]

I didn't focus on those concerns with this patch

Oh, I wan't suggesting you (or anyone else) should do these things now, only that it would be nice if eventually they got done.

[martindurant]

To specifically answer:

we'd probably need to bundle more concerns into the same PR.

I have no real preference - whatever works for the kind contributor (you or someone else).

[amotl]

Thanks. I am happy to bring in more adjustments, but it looks like @dwskoog is already starting per GH-485 and GH-486. Thank you!

If you are interested, the flake8 setup should really be included as a precommit hook as with other repos.

Do you mean relevant setup instructions should be added to the documentation like this PR is updating the sandbox section about corresponding details? On the other hand, @dwskoog already satisfied CI with GH-485, related to flake8 failures -- did you mean that?

Also, the supported python versions are out of date.

I think GH-486 already makes an effort on this, thank you again @dwskoog. 💯

@martindurant: I've rebased the patch, so another CI run might succeed now. Please let me know if you would like to see any other changes.

[dwskoog]

Thanks. I am happy to bring in more adjustments, but it looks like @dwskoog is already starting per GH-485 and GH-486. Thank you!

My company needs to get this project running on 3.14 for our next tech debt elimination. Part of our product is still on 3.11 because of the conflict between Streamz 0.6.4 and Python 3.12.

Also, the supported python versions are out of date.

I think GH-486 already makes an effort on this, thank you again @dwskoog. 💯

3.9 is EOL. If you look at the build logs for the 3.9 run in the test matrix, there are already looming dependency problems:

../../../../../usr/share/miniconda/envs/test_env/lib/python3.9/site-packages/dask/dataframe/_pyarrow_compat.py:15
  /usr/share/miniconda/envs/test_env/lib/python3.9/site-packages/dask/dataframe/_pyarrow_compat.py:15: FutureWarning: Minimal version of pyarrow will soon be increased to 14.0.1. You are using 10.0.1. Please consider upgrading.
    warnings.warn(

I am a bit perplexed by this as pyarrow 14.0.1 has 3.9 wheels in PyPI for manylinux_2_{17,28} so something else in conda's resolver is finding a conflict and settling on 10.0.1 as the newest viable solution. If it were actually dead, I would have removed it from the 3.13 branch and explained why, but it is still technically viable so I saw no reason to exclude it from the test matrix and thereby remove support. If @martindurant wants it out, I can easily do that in my PR while adding 3.13 or when adding 3.14 to the test matrix after incorporating your branch later.

3.10 hits EOL in 2026-10 so that will be a further problem sometime in 2027 most likely when the pyarrow/dask/cudf worlds get tired of supporting it.