In the upstream source tree, ruff has a small Python module in the folder python/ruff, which acts as a wrapper for locating the ruff binary. This module can currently be installed using the `ruff' Python module from PyPi. Unfortunately, this also bundles the complete ruff binary as well. In my eyes, it would make sense to install the Python module with dev-util/ruff, so I don't need to have two different ruff binaries when using Python modules that depend on `ruff' (python-lsp-ruff for example). Reproducible: Always
commit f7adbdf82e5916dbad4b53e415ac66bceb0fd938 Author: Eli Schwartz <eschwartz93@gmail.com> Date: Thu Feb 29 22:40:08 2024 -0500 dev-util/ruff: cut down on number of programs built / installed It is neither necessary nor desirable to compile and install every conceivable crate in the ruff source code. - ruff_dev is "an internal CLI for developers of Ruff" - ruff_python_formatter is just the source code for `ruff format`, but compiled standalone with a barebones main.rs for faster dev iteration - libruff_wasm.so exists solely to implement https://play.ruff.rs which would matter if we were packaging www-apps/ruff, or if we were using `--target web`, neither of which is true - libruff_macros.so is an internal proc-macro and it makes no sense that it should build a .so to begin with... We only care about two things: - ruff, the cli program - ruff_shrinking, which is a debug tool for producing minimal testcases of an issue. It is theoretically useful, so can't hurt to distribute. * FILES:-usr/bin/ruff_dev * FILES:-usr/bin/ruff_python_formatter * FILES:-usr/lib64/libruff_macros.so * FILES:-usr/lib64/libruff_wasm.so * SONAME:-libruff_macros.so(64) * SONAME:-libruff_wasm.so(64) * SIZE: 77.00MiB -> 37.74MiB, 33 -> 29 files * ------> FILES(-4) SONAME(-2) SIZE(-50.99%) Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org>
Sorry, I actually meant: commit 217dcaacf2d5fbcb9e5ed09a3cb4deee4c15791f Author: Eli Schwartz <eschwartz93@gmail.com> Date: Thu Feb 29 22:05:11 2024 -0500 dev-util/ruff: install as a standard cargo project The python module has no functionality. It can be used solely as: ``` python3.11 -m ruff ``` in which case it will check for sys.prefix + '/bin/ruff' and try to run it. The downside of trying to install it as a python project is that it: - adds fuzzy USE flags on python version - recompiles everything once per python impl, despite attempts at copying sources around - adds extra dependencies on e.g. maturin - generally complicates the ebuild We don't need any of that since this is just a cargo program. Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org>
(In reply to Moritz Brunner from comment #0) > In my eyes, it would make sense to install the Python module with > dev-util/ruff, so I don't need to have two different ruff binaries when > using Python modules that depend on `ruff' (python-lsp-ruff for example). python-lsp-ruff checks for an installed "ruff" program in a few different ways: https://github.com/python-lsp/python-lsp-ruff/blob/041c695d829239345ee9dd5c1f017311d6725ff0/pylsp_ruff/plugin.py#L492-L519 If there is an `import ruff` module it will try to use `python -m ruff`. If not, it tries `shutil.which('ruff')`, i.e. /usr/bin/ruff The latter always works. Can you elaborate on why you think python-lsp-ruff needs the bundled python module?
My bad, I was looking at pyproject.toml's dependencies section, and was assuming an unconditional dependency. In addition, the unit tests fail even though ruff is available in PATH, but I haven't taken a deeper look at this particular problem yet.
Possibly relevant by the way: https://github.com/python-lsp/python-lsp-ruff/issues/100
