-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation request #235
Comments
Hi! I wrote The intent of
It's used, for instance, in the github actions in this repository, to reduce ci runtime by building xapian once (per platform+python+xapian version, per cache lifetime) and reusing the wheel across matching runs. (see: .github/workflows/test.yml) For a random one-off virtualenv, I'd probably just use The script itself describes how to run it, but the gist of it is give it a xapian version, optionally a path to a specific version of python3, get a wheel. Building the wheel is done in a temporary virtualenv, not in any viritualenv you may or may not have active. As for where the script lives, it was meant to be an alternative to xapian-haystack's |
Thanks for the reply. BTW, I have discovered yet another xapian installation method. |
Hi,
The repo has the script
xapian_wheel_builder.sh
but it's not mentioned in the documention (which is the README file, correct?).How about adding this to the README?
xapian_wheel_builder.sh
to install xapian. (even if that is only two lines of code. An explanation of what it is, show how to run it)install_xapian.sh
andxapian_wheel_builder.sh
? Why would you prefer one or the other? In which cases would you use one or the other? Which is recommended? What would happen if you runxapian_wheel_builder.sh
in a venv or not in a venv? (I built the wheel without manually activating a venv. The wheel build succeeded, so maybe not important).Or add a
docs/advanced_topics.md
file, and elaborate there without any restrictions. :-)The text was updated successfully, but these errors were encountered: