Is it possible not to force dependency on Rust? #1405
Comments
|
UPD. I apologize, I should have checked README first. Apparently Rust can be disabled, and it is MacPorts fault not to consider that. I close this and will make a PR to MacPorts. |
|
|
That's just importing setuptools_rust, it's not actually running rust until the rust modules are built, which can be disabled with --pure or the PURE environment variable. |
|
Ok, got it, then I can perhaps can patch it out. P. S. MacPorts requires Rust for setuptools-rust (which could be wrong, I have no idea). |
|
python doesn't really have the concept of optional dependencies for setup.py, so on dulwich side we can't do much here. If you want to disable the rust extensions on Mac you could indeed just patch out the rust bits in setup.py. I think setuptools_rust should probably not have a hard dependency on rust, but a recommends or something like that (I'm not sure if macports has that concept) |
|
Ok, perhaps I got it working. Needed to patch Does it make sense to restore C extensions (on legacy systems where Rust is broken)? |
|
What platform are you using? rust should in general work fine on Mac OS X. |
Not on PowerPC. (At least not until Early x86 systems also have troubles with Rust. P. S. I think Rust is also broken on |
|
Ah, I see :-( Unfortunately maintaining two sets of extensions is too much of a pain, and since the extensions are optional I'm afraid I'd rather recommend people disable them on those platforms. I'd also accept PRs to automatically enable pure mode on platforms that won't support building the extensions. |
|
Closing this for now; please do comment/reopen if you have more concerns. |
|
Thank you. Yes, it is very much understandable that maintaining a separate C implementation is a burden, especially given that user impact is small. |
12 tasks
|
I ran into this too. setuptools_rust requires a rust to be installed. The only way to resolve it was to drop the setuptools_rust require and the RustExtensions usage. It is not a matter of the system being capable to run Rust or not, it is the ability to install dulwich as Pure Python code from source on a system not having Rust. |
|
Setuptools_rust shouldn't depend on rust - that might be a choice of your package manager. |
In fact it should depend on rust, because that's the only way to use setuptools_rust. Optional dependencies don't help because then no nothing can actually depend on something that is merely optional. The issue here is that dulwich conditionally uses RustExtension but doesn't conditionally import it.
It is absolutely possible to have optional dependencies for setup.py, since setup.py can augment pyproject.toml. In fact there are several build backends, such as meson-python and scikit-build-core, that natively do things like dynamically add additional build-requires if you don't yet have a system C++ level installation of cmake or ninja. The pyproject.toml specification shipped from day one with an accompanying hook for the specific use case of allowing build backends to specify additional build-requires. If I recall correctly, specifying setup requires in setup.py itself gets passed through to that hook, which means setuptools_rust would only be installed when the environment variable to disable it isn't defined. |
I'd agree that it isn't particularly helpful without pulling in rust, but setuptools_rust itself is perfectly importable without having rust installed. Having a hard dependency on rust is a choice on the macports side.
At a glance I don't see how that would address the issue; we need to import from setuptools_rust before calling setup() and if we stopped specifying a build-requires on setuptools_rust, then we'd presumably need to call setup() to declare the dependency on setuptools_rust. Happy to be convinced that I'm wrong and open to PRs - so long as that doesn't mean switching to a completely different build system. |
eli-schwartz
added a commit
to eli-schwartz/dulwich
that referenced
this issue
Nov 5, 2024
When a pure build is requested, no compiled extensions are produced. The setuptools_rust dependency ends up imported-but-not-used. Teach setuptools to avoid build-requiring it in this case. Unfortunately, setuptools deprecated the setup_requires keyword which is intended to do this and replaced it with confusing advice that users should implement their own build backend that subclasses setuptools. It's a bit more busywork to do as the setuptools documentation suggests but at least the result is as expected. Closes: jelmer#1405 Bug: pypa/setuptools#2854 Buggy: pypa/setuptools#2897
eli-schwartz
added a commit
to eli-schwartz/dulwich
that referenced
this issue
Nov 5, 2024
When a pure build is requested, no compiled extensions are produced. The setuptools_rust dependency ends up imported-but-not-used. Teach setuptools to avoid build-requiring it in this case. Closes: jelmer#1405
jelmer
added a commit
that referenced
this issue
Nov 5, 2024
When a pure build is requested, no compiled extensions are produced. The setuptools_rust dependency ends up imported-but-not-used. Teach setuptools to avoid build-requiring it in this case. Closes: #1405
|
@grobian this is fixed in the linked PR, thanks for the commits to dev-python/dulwich that made me notice this. :) We can remove our hacks in a bit, I guess. |
|
Could you say how to pass |
|
In general, passing options on the command line to setuptools is "hard" unless you avoid pep 517 and invoke |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recent update pulled in Rust and a lot of related stuff as dependencies. This is undesirable both due to just being heavy and due to Rust being broken on some non-mainstream platforms (which makes it impossible to install this at all).
The text was updated successfully, but these errors were encountered: