Consider adding native binary target for cargo installation

[joshuadavidthomas]

Currently the server is distributed as a PyO3 extension module on PyPI but since we no longer require local installation (#62), we could also offer a native Rust binary via cargo install. The code is already structured for this with clap CLI handling - would just need to add a binary target and expose some internals.

[joshuadavidthomas]

I tried to pursue this, but ran into shared library errors. We don't require local installation, but for some reason keeping it as an extension module and wrapping the CLI in a light Python wrapper seems to be more reliable?

Now, it could totally be my local dev setup not being correct -- the Python environment is 3.13 in the LSP repo, but I tried to install it via uv pip install ~/projects/django-language-server in a project that uses Python 3.12 and I got a missing .so shared library for libpython for 3.12.

Yet, keeping it the way it is now, it installs fine and is able to run and correctly use the project's Python version (instead of the build env's 3.13). I'm a bit out of my league on this one, as this is the first serious Python extension written in another language I've ever tried to do. Pretty sure this should be possible, I'm just afraid I'll need a bit more experience in this area to actually troubleshoot and fix it.

In the end, I'm not sure it really matters other than not being able to cargo install from source -- but that may be irrelevant since you can just pip install it. I'll leave this open for now, in case someone with more experience in this area just happens upon it and knows exactly what's up.

[joshuadavidthomas]

I don't know if I got to the bottom of it, but definitely figured out some things about linking and shared libraries in #118. Now all the crates that use the py object from PyO3 have a build script that finds the correct Python interpreter. Could be useful for exploring this? Maybe it even solved it!

[joshuadavidthomas]

LOL nope. Tried to go down this path again, and hit wall after wall. Either a skill issue or this is a fruitless pursuit. More importantly, the current cdylib approach with the Python entrypoint just works. At this point, that's all I care about.