ruff icon indicating copy to clipboard operation
ruff copied to clipboard

Document behavior and support around python version

Open vikigenius opened this issue 3 years ago • 10 comments
trafficstars

Looking at the README it is not exactly clear how ruff supports different python versions.

I saw the target_version option that talks about minimum supported python. But how low can we go? Does it support python 2 ?

Additionally is it supported to run ruff using python -m ruff to ensure that the correct version of ruff is run in the presence of global installations and multiple virtual environments?

vikigenius avatar Nov 05 '22 00:11 vikigenius

@charliermarsh upon further testing I have learned that ruff does not actually support calling it as a module

For eg: python -m flake8 <src> works but python -m ruff <src> would complain about no module named ruff

Do you plan on supporting python -m ruff usage? I can create a separate issue for that.

All it needs is for there to actually be a ruff module that is the main entry point. For example flake8 has a top level flake8 package and the following file https://github.com/PyCQA/flake8/blob/main/src/flake8/main.py that allows python -m flake8 usage.

vikigenius avatar Nov 07 '22 19:11 vikigenius

Actually never mind I just realized that ruff is installed as just an executable and not a python module, thus there is no way to support python -m, still the concerns about python version etc. hold and should be documented.

vikigenius avatar Nov 08 '22 05:11 vikigenius

Sorry for the delay here. Yeah, right now we're just shipping the binary and not an actual Python module. We could change this! It's totally possible for us to ship a Python module (in fact, I want to ship a Python API for the Ruff API too), it just adds a bit of complication so I've been putting it off.

charliermarsh avatar Nov 08 '22 14:11 charliermarsh

Let's create a separate issue for python -m ruff, and use this for documenting target version support.

charliermarsh avatar Nov 08 '22 14:11 charliermarsh

it just adds a bit of complication so I've been putting it off.

Could you please elaborate on that? I've done some reading and doing #658 and #659 seems doable, maturin doesn't yet support building one wheel with both a binary and a library:

https://github.com/PyO3/maturin/issues/368

squiddy avatar Nov 09 '22 05:11 squiddy

You don't need to ship both a binary and a library to support python -m ruff, you can add a __main__.py and execv the ruff executable.

For example, https://github.com/PyO3/maturin/blob/main/maturin/main.py

messense avatar Nov 09 '22 09:11 messense

@squiddy - Interesting, I think I'd just assumed it was possible to build a single wheel for both a binary and a library. That's good to know. It seems from the issue that it may be possible to do at some point? I believe Maturin now supports shipping multiple binaries in the same wheel.

charliermarsh avatar Nov 09 '22 14:11 charliermarsh

@messense - Naive question, but in that scheme, can users still execute the Ruff executable directly? Or does invocation always go through Python?

In other words: would ruff still work, or would users have to use python -m ruff? If the former, would calling ruff start a Python interpreter to call through to the Ruff executable? Or would it call the executable directly?

charliermarsh avatar Nov 09 '22 14:11 charliermarsh

ruff still works as long as Python scripts directory is in PATH, it's same as current setup, no Python interpreter is involved when invoking ruff directly.

messense avatar Nov 09 '22 14:11 messense

IIUC target_version is mostly used by the pyupgrade checks.

tekumara avatar Nov 21 '22 00:11 tekumara