internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: scikit-hep/pyhf

Issue:
Guard SCHEMA_VERSION from version bumps
I don't think it is going to be possible to guard the `SCHEMA_VERSION` from `bump2version` so we might need to look for a replacement for `bump2version` that gives guard support.

This is going to be a problem when 

https://github.com/scikit-hep/pyhf/blob/6b0a9317b14da2a452f51d089cb9e493c8f19347/.bumpversion.cfg#L1-L2

hits `1.0.0` and conflicts with 

https://github.com/scikit-hep/pyhf/blob/f824afe77d9e48e90651931700ccfc3d3c268c18/src/pyhf/utils.py#L13

and also has to properly pick up the multiple correct instances in 

https://github.com/scikit-hep/pyhf/blob/f824afe77d9e48e90651931700ccfc3d3c268c18/src/pyhf/utils.py#L145

_Originally posted by @matthewfeickert in https://github.com/scikit-hep/pyhf/issues/1218#issuecomment-744590434_


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -68,7 +68,7 @@
         + extras_require['test']
         + [
             'nbdime',
-            'bump2version',
+            'tbump>=6.7.0',
             'ipython',
             'pre-commit',
             'check-manifest',


Test patch:
Repository: scikit-hep/pyhf

Issue:
Explore pyodide for pyhf
### Summary

Pyodide allows pure-python wheels to be "imported" into the browser and run as-is.. this means we could ship an interactive console as part of our docs that just.. works.. 

https://pyodide.org/en/stable/index.html

However, one of our main dependencies is on scipy which is currently being worked on (pyodide/pyodide#1293) but it seems like all of our other deps should be ok.

### Additional Information

_No response_

### Code of Conduct

- [X] I agree to follow the Code of Conduct


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -52,6 +52,7 @@ def setup(app):
     'nbsphinx',
     'sphinx_issues',
     'sphinx_copybutton',
+    'sphinx_togglebutton',
     'xref',
 ]
 bibtex_bibfiles = [
diff --git a/docs/generate_jupyterlite_iframe.py b/docs/generate_jupyterlite_iframe.py
new file mode 100644
--- /dev/null
+++ b/docs/generate_jupyterlite_iframe.py
@@ -0,0 +1,30 @@
+import urllib.parse
+
+
+def main():
+    code = """\
+import piplite
+await piplite.install(["pyhf==0.6.3", "requests"])
+%matplotlib inline
+import pyhf\
+"""
+
+    parsed_url = urllib.parse.quote(code)
+    url_base = "https://jupyterlite.github.io/demo/repl/index.html"
+    jupyterlite_options = "?kernel=python&toolbar=1&code="
+    jupyterlite_url = url_base + jupyterlite_options + parsed_url
+
+    print(f"# jupyterlite URL:\n{jupyterlite_url}")
+
+    jupyterlite_iframe_rst = f"""\
+   <iframe
+      src="{jupyterlite_url}"
+      width="100%"
+      height="500px"
+   ></iframe>\
+"""
+    print(f"\n# RST for iframe for jupyterlite.rst:\n{jupyterlite_iframe_rst}")
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -59,6 +59,7 @@
             'ipywidgets',
             'sphinx-issues',
             'sphinx-copybutton>=0.3.2',
+            'sphinx-togglebutton>=0.3.0',
         ]
     )
 )


Test patch:
Repository: scikit-hep/pyhf

Issue:
Add linkcheck to docs workflows
With the addition of [user-defined build jobs in ReadTheDocs](https://twitter.com/readthedocs/status/1519363742869295105?s=11&t=5-u_2BFwXLAj9IyXQLhIVA) I noticed that one of their examples was to [perform a check for broken links]( https://docs.readthedocs.io/en/latest/build-customization.html#perform-a-check-for-broken-links) with `sphinx`'s `linkcheck`.

I'm working on adding this both to the ReadTheDocs config and to the docs GHA workflow, but at the moment

```console
$ cd docs
$ make linkcheck
```

is giving a failure

```
(           babel: line    3) broken    cli.html#pyhf-xml2json -
```

on

https://github.com/scikit-hep/pyhf/blob/e7996e5ba350a48825d9736ccc81ca8e3009dd3c/docs/babel.rst?plain=1#L5

I'm not quite sure why, as this is a valid link once the source is built, but I think it might be a form of https://github.com/sphinx-doc/sphinx/issues/9383.

I have this and other fixes on a branch named `docs/use-read-the-docs-pre-build-job`.


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -462,3 +462,7 @@ def setup(app):
         }
     },
 }
+
+# c.f. https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-the-linkcheck-builder
+linkcheck_ignore = ['cli.html#pyhf-xml2json']
+linkcheck_retries = 50


Test patch:
Repository: scikit-hep/pyhf

Issue:
Use string form for type checking until Python 3.7 dropped
What the if here? The string form is fine until you drop Pythons that don’t support it.

_Originally posted by @henryiii in https://github.com/scikit-hep/pyhf/pull/1909#discussion_r944456765_

This was in reference to 

```python
if T.TYPE_CHECKING:
    PathOrStr = T.Union[str, os.PathLike[str]]
else:
    PathOrStr = T.Union[str, "os.PathLike[str]"]
```

in PR #190 now in 

https://github.com/scikit-hep/pyhf/blob/ad1dd86f1d7c1bcbf737805b6821e07c4ef75fca/src/pyhf/typing.py#L30-L33

So until Python 3.7 is dropped (I think this is the version I am not very up to date with my type checking knowledge) we could instead just drop the `if TYPE_CHECKING` and use

```python
#TODO: Switch to os.PathLike[str] once Python 3.7 dropped
PathOrStr = Union[str, "os.PathLike[str]"]
```

This would also allow for reverting PR #1937.


Discussion:

Resolving patch:
diff --git a/src/pyhf/typing.py b/src/pyhf/typing.py
--- a/src/pyhf/typing.py
+++ b/src/pyhf/typing.py
@@ -1,6 +1,6 @@
 import os
 import sys
-from typing import TYPE_CHECKING, MutableSequence, Sequence, Union
+from typing import MutableSequence, Sequence, Union
 
 if sys.version_info >= (3, 8):
     from typing import Literal, TypedDict
@@ -27,10 +27,8 @@
     "Workspace",
 )
 
-if TYPE_CHECKING:
-    PathOrStr = Union[str, os.PathLike[str]]
-else:
-    PathOrStr = Union[str, "os.PathLike[str]"]
+# TODO: Switch to os.PathLike[str] once Python 3.8 support dropped
+PathOrStr = Union[str, "os.PathLike[str]"]
 
 
 class ParameterBase(TypedDict, total=False):


Test patch:
Repository: scikit-hep/pyhf

Issue:
Add `https://pyhf.readthedocs.io/en/v` to linkcheck_ignore
During release will get

```
(             faq: line   13) broken    https://pyhf.readthedocs.io/ - 404 Client Error: Not Found for url: https://pyhf.readthedocs.io/en/v0.7.0/
```

As that doesn't exist yet. So should add it to

https://github.com/scikit-hep/pyhf/blob/931dd36cf573c4dbb4853494da18f4df07910af1/docs/conf.py#L497-L505

like we did with `https://github.com/scikit-hep/pyhf/releases/tag/.*` in PR #1705.


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -500,7 +500,9 @@ def setup(app):
     r'https://doi\.org/10\.31526/.*',
     # https://doi.org/10.1051/epjconf/x DOI URLs will periodically generate 500 Server Error
     r'https://doi\.org/10\.1051/epjconf/.*',
-    # tags for a release won't exist until it is made, but the release notes need to reference them
+    # tags for a release won't exist until it is made, but the release notes
+    # and ReadTheDocs need to reference them
     r'https://github.com/scikit-hep/pyhf/releases/tag/.*',
+    r'https://pyhf.readthedocs.io/en/.*',
 ]
 linkcheck_retries = 50


Test patch:
Repository: scikit-hep/pyhf

Issue:
docs build failing on Pygments lexter warning
Hm. Something related to https://github.com/spatialaudio/nbsphinx/issues/24 is breaking the docs build. We're getting

```pytb
WARNING: Pygments lexer name 'ipython3' is not known
```

for all the notebooks during the docs build and we fail on warnings.

_Originally posted by @matthewfeickert in https://github.com/scikit-hep/pyhf/issues/2066#issuecomment-1329937208_
      


Discussion:
Given that

```console
$ python -m pip show Pygments | grep Required-by
Required-by: ipython, jupyter-console, nbconvert, nbdime, qtconsole, readme-renderer, rich, Sphinx
```

and between the last working build of the docs on 2022-11-17 and now (2022-11-28) the difference in installed dependencies includes

```diff
$ diff --color -u /tmp/pass.txt /tmp/fail.txt
...
-ipykernel                     6.17.1
-ipython                       8.6.0
+ipykernel                     6.18.1
+ipython                       8.7.0
```

I'm going to assume there is something different with `ipython` and look there.
This shows up in https://github.com/ipython/ipython/issues/13845 as well, so I think that this is going to exist for a bit and that PR #2066 should get merged in while this all gets figured out.

It does seem that https://github.com/ipython/ipython/issues/13845#issuecomment-1329226997 is correct though about

> this is due to the Pygments entry points not being correctly installed with ~8.6.0~ 8.7.0 as

```console
$ python -m pip list | grep 'setuptools\|ipython'                                                
ipython                       8.7.0
ipython-genutils              0.2.0
setuptools                    65.6.3
$ python -c 'from importlib.metadata import entry_points; print(entry_points(group="pygments.lexers"))'
[]
$ python -m pip install --upgrade 'ipython==8.6.0'
$ python -m pip list | grep 'setuptools\|ipython'                                                                                                         
ipython                       8.6.0
ipython-genutils              0.2.0
setuptools                    65.6.3
$ python -c 'from importlib.metadata import entry_points; print(entry_points(group="pygments.lexers"))'                                                   
[EntryPoint(name='ipython', value='IPython.lib.lexers:IPythonLexer', group='pygments.lexers'), EntryPoint(name='ipython3', value='IPython.lib.lexers:IPython3Lexer', group='pygments.lexers'), EntryPoint(name='ipythonconsole', value='IPython.lib.lexers:IPythonConsoleLexer', group='pygments.lexers')]
```

so to get around this just disallow `ipython` `v8.7.0` for the time being

```
ipython!=8.7.0
```

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -58,6 +58,7 @@
             'sphinx-issues',
             'sphinx-copybutton>=0.3.2',
             'sphinx-togglebutton>=0.3.0',
+            'ipython!=8.7.0',  # c.f. https://github.com/scikit-hep/pyhf/pull/2068
         ]
     )
 )


Test patch:
Repository: scikit-hep/pyhf

Issue:
Menu on mobile page not accessible for pyhf v0.7.1 docs
### Summary

On the [`pyhf` `v0.7.1` docs](https://pyhf.readthedocs.io/en/v0.7.1/) and on the `main` docs build the drop down menu (circled in screen shot bellow) fails to open when clicked on.

![mobile-dropdown-menu-fail](https://user-images.githubusercontent.com/5142394/235338106-4c6afbeb-d35f-494d-b8f3-7202625ef203.jpg)

Things work fine on desktop and confusingly @alexander-held has pointed out that the [`v0.5.2` `cabinetry` docs](https://cabinetry.readthedocs.io/en/stable/) (where were [released](https://github.com/scikit-hep/cabinetry/releases/tag/v0.5.2) very close in time to the `pyhf` `v0.7.1` docs) have a menu that works fine on mobile.

### Documentation Page Link

https://pyhf.readthedocs.io/en/v0.7.1/

### Code of Conduct

- [X] I agree to follow the Code of Conduct


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -55,6 +55,7 @@ def setup(app):
     'sphinx.ext.viewcode',
     'sphinx.ext.githubpages',
     'sphinx.ext.intersphinx',
+    'sphinx_rtd_theme',
     'sphinxcontrib.bibtex',
     'sphinx.ext.napoleon',
     'sphinx_click.ext',


Test patch:
Repository: scikit-hep/pyhf

Issue:
Upcoming deprecation of np.product
### Summary

Both `paramview` and `pdf` cause deprecation warnings due to the use of `np.product` instead of `np.prod` when using `numpy` 1.25 or above. This is not flagged in CI, which uses an older version of `numpy`, presumably due to other dependencies capping it still.

### OS / Environment

```console
n/a
```


### Steps to Reproduce

run e.g. `pytest tests/test_pdf.py` in an environment with `numpy` 1.25

### File Upload (optional)

_No response_

### Expected Results

no deprecation warnings

### Actual Results

```console
[...]/pyhf/src/pyhf/parameters/paramview.py:65: DeprecationWarning: `product` is deprecated as of NumPy 1.25.0, and will be removed in NumPy 2.0. Please use `prod` instead.
    fullsize = default_backend.product(default_backend.astensor(shape))

  [...]/pyhf/src/pyhf/pdf.py:709: DeprecationWarning: `product` is deprecated as of NumPy 1.25.0, and will be removed in NumPy 2.0. Please use `prod` instead.
    newbysample = tensorlib.product(allfac, axis=0)
```


### pyhf Version

```console
HEAD
```


### Code of Conduct

- [X] I agree to follow the Code of Conduct


Discussion:

Resolving patch:
diff --git a/src/pyhf/tensor/numpy_backend.py b/src/pyhf/tensor/numpy_backend.py
--- a/src/pyhf/tensor/numpy_backend.py
+++ b/src/pyhf/tensor/numpy_backend.py
@@ -254,7 +254,7 @@ def sum(self, tensor_in: Tensor[T], axis: int | None = None) -> ArrayLike:
         return np.sum(tensor_in, axis=axis)
 
     def product(self, tensor_in: Tensor[T], axis: Shape | None = None) -> ArrayLike:
-        return np.product(tensor_in, axis=axis)  # type: ignore[arg-type]
+        return np.prod(tensor_in, axis=axis)  # type: ignore[arg-type]
 
     def abs(self, tensor: Tensor[T]) -> ArrayLike:
         return np.abs(tensor)


Test patch:
diff --git a/docs/examples/notebooks/pytorch_tests_onoff.ipynb b/docs/examples/notebooks/pytorch_tests_onoff.ipynb
--- a/docs/examples/notebooks/pytorch_tests_onoff.ipynb
+++ b/docs/examples/notebooks/pytorch_tests_onoff.ipynb
@@ -35,7 +35,7 @@
     "            self.auxdata.append(bkg_over_bsq)\n",
     "\n",
     "    def alphas(self, pars):\n",
-    "        return np.product([pars, self.bkg_over_db_squared], axis=0)\n",
+    "        return np.prod([pars, self.bkg_over_db_squared], axis=0)\n",
     "\n",
     "    def logpdf(self, a, alpha):\n",
     "        return _log_poisson_impl(a, alpha)\n",
Repository: scikit-hep/pyhf

Issue:
Sphinx warning in docs for config value `jupyterlite_dir` has type `str`, defaults to `PosixPath`
Following Issue #2297, the test build of the docs is failing with

```
WARNING: The config value `jupyterlite_dir' has type `str', defaults to `PosixPath'.
```

This warning is treated as an error as we do this intentionally 

https://github.com/scikit-hep/pyhf/blob/b6874878c58093f8c1fecc06d2f631fa82e6e064/docs/Makefile#L5-L8

I'm not sure if this means that we need to update

https://github.com/scikit-hep/pyhf/blob/b6874878c58093f8c1fecc06d2f631fa82e6e064/docs/conf.py#L531-L532

to be a Pathlib Path or not. I'm not sure how that would work though.


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -529,4 +529,5 @@ def setup(app):
 linkcheck_retries = 50
 
 # JupyterLite configuration
-jupyterlite_dir = "lite"
+# Use Path as jupyterlite-sphinx expects PosixPath
+jupyterlite_dir = Path("lite")


Test patch:
Repository: scikit-hep/pyhf

Issue:
In Python 3.12 tarfile raises DeprecationWarning: Python 3.14 will, by default, filter extracted tar archives and reject files or modify their metadata.
While testing Python 3.12 in CI

https://github.com/scikit-hep/pyhf/blob/adddb0797c564a0158a8e2e69a58ee1f98604bf7/tests/test_scripts.py#L591-L604

raised

```pytb
>       assert ret.success
E       assert False
E        +  where False = <pytest_console_scripts.RunResult object at 0x29fd18b90>.success
...
DeprecationWarning: Python 3.14 will, by default, filter extracted tar archives and reject files or modify their metadata. Use the filter argument to control this behavior.
```

This should get fixed before Python 3.12 support is added.


Discussion:
c.f. https://docs.python.org/3.12/library/tarfile.html#tarfile-extraction-filter and [PEP 706 – Filter for `tarfile.extractall`](https://peps.python.org/pep-0706/).

Resolving patch:
diff --git a/src/pyhf/contrib/utils.py b/src/pyhf/contrib/utils.py
--- a/src/pyhf/contrib/utils.py
+++ b/src/pyhf/contrib/utils.py
@@ -91,7 +91,12 @@ def download(archive_url, output_directory, force=False, compress=False):
                     with tarfile.open(
                         mode="r:*", fileobj=BytesIO(response.content)
                     ) as archive:
-                        archive.extractall(output_directory)
+                        # TODO: Simplify after pyhf is Python 3.12+ only
+                        # c.f. https://docs.python.org/3.12/library/tarfile.html#extraction-filters
+                        if hasattr(tarfile, "data_filter"):
+                            archive.extractall(output_directory, filter="data")
+                        else:
+                            archive.extractall(output_directory)
                 except tarfile.ReadError:
                     if not zipfile.is_zipfile(BytesIO(response.content)):
                         raise exceptions.InvalidArchive(


Test patch:
Repository: scikit-hep/pyhf

Issue:
In Python 3.12  xml.etree.ElementTree will raise DeprecationWarning: Testing an element's truth value will raise an exception in future versions
While testing Python 3.12 in CI

https://github.com/scikit-hep/pyhf/blob/adddb0797c564a0158a8e2e69a58ee1f98604bf7/tests/test_export.py#L438-L450

raised 

```pytb
>       assert channel
E       DeprecationWarning: Testing an element's truth value will raise an exception in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.
```

This comes from https://github.com/python/cpython/issues/83122 which landed in Python 3.12. This should get fixed before Python 3.12 support is added.

From the Python 3.12 docs: https://docs.python.org/3.12/library/xml.etree.elementtree.html#element-objects

> Caution: Elements with no subelements will test as `False`. Testing the truth value of an Element is deprecated and will raise an exception in Python 3.14. Use specific `len(elem)` or `elem is None` test instead.:
>
>
> ```python
> element = root.find('foo')
> 
> if not element:  # careful!
>     print("element not found, or element has no subelements")
> 
> if element is None:
>     print("element not found")
> ```
>
> _Changed in version 3.12_: Testing the truth value of an Element emits [DeprecationWarning](https://docs.python.org/3/library/exceptions.html#DeprecationWarning).


Discussion:

Resolving patch:
diff --git a/src/pyhf/writexml.py b/src/pyhf/writexml.py
--- a/src/pyhf/writexml.py
+++ b/src/pyhf/writexml.py
@@ -56,7 +56,7 @@ def _export_root_histogram(hist_name, data):
 # https://stackoverflow.com/a/4590052
 def indent(elem, level=0):
     i = "\n" + level * "  "
-    if elem:
+    if elem is not None:
         if not elem.text or not elem.text.strip():
             elem.text = i + "  "
         if not elem.tail or not elem.tail.strip():


Test patch:
diff --git a/tests/test_export.py b/tests/test_export.py
--- a/tests/test_export.py
+++ b/tests/test_export.py
@@ -447,7 +447,7 @@ def test_integer_data(datadir, mocker):
     mocker.patch("pyhf.writexml._ROOT_DATA_FILE")
 
     channel = pyhf.writexml.build_channel(spec, channel_spec, {})
-    assert channel
+    assert channel is not None
 
 
 @pytest.mark.parametrize(
Repository: scikit-hep/pyhf

Issue:
Move documentation pages to PyData Sphinx Theme
### Summary

Hi all! After talking to @matthewfeickert , I was wondering if you folks are interested in moving to the PyData Sphinx Theme for your documentation pages. I have experimented with it and it would be a very simple PR. The advantage in doing this is that the PyData Sphinx Theme has been doing a number of usability, design and accessibility improvements to the theme, and it is widely adopted by other projects in the ecosystem.

Let me know what you think.

### Additional Information

Here is how it looks with minimal customization:

![Captura de imagem_20240605_102435](https://github.com/scikit-hep/pyhf/assets/3949932/eafc5927-1e40-4656-b2a2-612d6f9126da)



### Code of Conduct

- [X] I agree to follow the Code of Conduct


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -55,7 +55,6 @@ def setup(app):
     'sphinx.ext.viewcode',
     'sphinx.ext.githubpages',
     'sphinx.ext.intersphinx',
-    'sphinx_rtd_theme',
     'sphinxcontrib.bibtex',
     'sphinx.ext.napoleon',
     'sphinx_click.ext',
@@ -243,13 +242,13 @@ def setup(app):
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'sphinx_rtd_theme'
+html_theme = 'pydata_sphinx_theme'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
-html_theme_options = {}
+html_theme_options = {"header_links_before_dropdown": 6}
 
 # Add any paths that contain custom themes here, relative to this directory.
 html_theme_path = []


Test patch:
Repository: cltk/cltk

Issue:
Importing CorpusImporter raises error
If I run: `from cltk.corpus.utils.importer import CorpusImporter`

I get:

```
Corpus not found. Please check that the Latin Library is installed in CLTK_DATA.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/site-packages/cltk/corpus/utils/importer.py", line 14, in <module>
    from cltk.corpus.old_english.corpora import OLD_ENGLISH_CORPORA
ImportError: No module named 'cltk.corpus.old_english'
```

This appears to be a regression introduced somewhere [between v0.1.39 and v0.1.41](https://github.com/cltk/cltk/compare/v0.1.39...v0.1.41). You can verify by using [`cltk_docker`](https://github.com/cltk/cltk_docker), if you change the `pip install --upgrade cltk` line in the `Dockerfile` to `pip install --upgrade cltk==0.1.39`, `install.py` will succeed, otherwise it will fail at the CorpusImporter import line (also happens if you specify `pip install --upgrade git+git://github.com/cltk/cltk.git` for the latest git revision).



Discussion:

Resolving patch:
diff --git a/cltk/corpus/old_english/__init__.py b/cltk/corpus/old_english/__init__.py
new file mode 100644


Test patch:
Repository: cltk/cltk

Issue:
Inconsistent case of data directory
[The latin module](https://github.com/cltk/cltk/blob/36b6fe7aa23a8c4f41ef694ddb64b4b02534146c/cltk/corpus/latin/__init__.py#L20) tries to load the latin library from "~/CLTK_DATA", which fails on a case-sensitive filesystem.

All other modules seem to use "~/cltk_data", so that should be standardized. 

(It would probably be best if the path was factored out and also configurable, but fixing at least that one inconsistency lets me actually import stuff without errors.)

Inconsistent case of data directory
[The latin module](https://github.com/cltk/cltk/blob/36b6fe7aa23a8c4f41ef694ddb64b4b02534146c/cltk/corpus/latin/__init__.py#L20) tries to load the latin library from "~/CLTK_DATA", which fails on a case-sensitive filesystem.

All other modules seem to use "~/cltk_data", so that should be standardized. 

(It would probably be best if the path was factored out and also configurable, but fixing at least that one inconsistency lets me actually import stuff without errors.)



Discussion:
Stefan, thanks for this. We can fix this immediately. Would you like to make the PR?

Stefan, thanks for this. We can fix this immediately. Would you like to make the PR?


Resolving patch:
diff --git a/cltk/corpus/latin/__init__.py b/cltk/corpus/latin/__init__.py
--- a/cltk/corpus/latin/__init__.py
+++ b/cltk/corpus/latin/__init__.py
@@ -17,7 +17,7 @@
 # Would like to have this search through a CLTK_DATA environment variable
 # Better to use something like make_cltk_path in cltk.utils.file_operations?
 home = os.path.expanduser('~')
-cltk_path = os.path.join(home, 'CLTK_DATA')
+cltk_path = os.path.join(home, 'cltk_data')
 
 word_tokenizer = WordTokenizer('latin')
 


Test patch: