v0.14.2 patch release, removing RTD PDF build

[argerlt]

I plan on leaving this open for a bit as additional potential downstream pipeline problems are reported, but this includes optional solutions to address #611, #613, and #616

1) (optional) make Arrow3D a public facing class (removed, based on discussion in kikuchipy)
2) Remove the pdf build in ReadtheDocs
3) remove dependency on pycifrw and version restriction from pytest-rerunfailures, as the bugs necessitating both have been patched.

For reviewers

• The PR title is short, concise, and will make sense 1 year later.
• New functions are imported in corresponding __init__.py.
• New features, API changes, and deprecations are mentioned in the unreleased
  section in CHANGELOG.rst.
• Contributor(s) are listed correctly in __credits__ in orix/__init__.py and in
  .zenodo.json.

[argerlt]

@hakonanes, once the current kikuchipy patch 0.11.4 is done, assuming nothing new breaks in orix/pyxem/hyperspy/kikuchipy, this patch is probably good to go.

[hakonanes]

Now that we don't build the PDF, we should remove the nbsphinx prolog specifically for the PDF build:

orix/doc/conf.py

Lines 181 to 185 in 3db9eb7

	.. raw:: latex
	\nbsphinxstartnotebook{\scriptsize\noindent\strut
	\textcolor{gray}{The following section was generated from
	\sphinxcode{\sphinxupquote{\strut {{ docname | escape_latex }}}} \dotfill}}

[hakonanes]

I'm OK with leaving out the PDF. Thanks for making the change!

[hakonanes]

once the current kikuchipy patch 0.11.4 is done [...] this patch is probably good to go

Why do we have to wait kikuchipy? I suggest we finish this and release.

[argerlt]

Just an overabundance of caution, patches are moderately time consuming and I don't want to turn around and have to discuss patch 0.14.3 next week because an oversight broke kikuchipy or hyperspy.

The comment is less relevant though now that pyxem/kikuchipy#772 is showing all green lights. This can probably be merged ASAP.

[hakonanes]

Just an overabundance of caution, patches are moderately time consuming and I don't want to turn around and have to discuss patch 0.14.3 next week [...]

Valid point. To reduce the chance of this happening, we can start by releasing a release candidate (RC) prior releasing an actual release. The process would be:

1. Release an RC to PyPI with version MAJOR.MINOR.PATCHrc1, say, 0.15.0rc1
2. Ask dependents to run their test suit against the RC, e.g. with in a dedicated action where we explicitly install the most recent RS using pip install --pre orix (https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-pre)

I consider this approach a more light-weight version of what @ericpre is doing with HyperSpy, where the test suite of dependents in the ecosystem (exspy, pyxem, kikuchipy, etc.) are run quite frequently when making changes in HS.

[hakonanes]

Thanks for making the changes! Need to fix the date in the changelog, otherwise good!

[argerlt]

@hakonanes, another change: using pre-commit has made some of the code-style checks in the workflows redundant.

This recently became an issue because pre-commit and workflows are using slightly different versions of black that format certain files differently, thus causing every PR to fail one or the other.

Removing the check from workflows seems more maintainable, since pre-commit has autofix.

[argerlt]

Thanks for making the changes! Need to fix the date in the changelog, otherwise good!

I missed this, apologies. fixed!

[hakonanes]

Thanks for making these changes, @argerlt!

[hakonanes]

We forgot to bump the version, as per our release guide. I'll make a new PR.