cf-units not installing for python 3.11

[bjlittle]

🐛 Bug Report

How to Reproduce

Steps to reproduce the behaviour:

pip install cf-units

Generated the following output when using python=3.11.3 and pip=23.0.1

> conda create -n delme -c conda-forge python pip
> conda activate delme
> pip install cf-units
Collecting cf-units
  Using cached cf-units-3.1.1.tar.gz (188 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting antlr4-python3-runtime==4.7.2
  Using cached antlr4_python3_runtime-4.7.2-py3-none-any.whl
Collecting cftime>=1.2
  Using cached cftime-1.6.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.3 MB)
Collecting jinja2
  Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB)
Collecting numpy
  Using cached numpy-1.24.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.3 MB)
Collecting MarkupSafe>=2.0
  Using cached MarkupSafe-2.1.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (27 kB)
Building wheels for collected packages: cf-units
  Building wheel for cf-units (pyproject.toml) ... error
  error: subprocess-exited-with-error
  
  × Building wheel for cf-units (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [19 lines of output]
      Traceback (most recent call last):
        File "/home/h05/itwl/.conda/envs/delme/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/home/h05/itwl/.conda/envs/delme/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/h05/itwl/.conda/envs/delme/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 251, in build_wheel
          return _build_backend().build_wheel(wheel_directory, config_settings,
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/var/tmp/pip-build-env-m6cm44gz/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 413, in build_wheel
          return self._build_with_temp_dir(['bdist_wheel'], '.whl',
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/var/tmp/pip-build-env-m6cm44gz/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 398, in _build_with_temp_dir
          self.run_setup()
        File "/var/tmp/pip-build-env-m6cm44gz/overlay/lib/python3.11/site-packages/setuptools/build_meta.py", line 335, in run_setup
          exec(code, locals())
        File "<string>", line 152, in <module>
        File "<string>", line 75, in get_package_data
      ValueError: Require to set UDUNITS2_XML_PATH for a cf-units wheel build.
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for cf-units
Failed to build cf-units
ERROR: Could not build wheels for cf-units, which is required to install pyproject.toml-based projects

[trexfeathers]

Hasn't this always been the case?

cf-units/setup.cfg

Lines 35 to 43 in cf4d66d

	[options]
	include_package_data = True
	install_requires =
	antlr4-python3-runtime ==4.7.2
	cftime >=1.2
	jinja2
	numpy
	# udunits2 cannot be installed with pip, and it is expected to be
	# installed separately.

[ocefpaf]

Also, wheels were never built for 3.11. Maybe it is just a matter of issuing a post release to make that happen?

[shyft-eric]

I was getting this error as well when running a Dockerfile that used to work just fine, not even using Conda. After reviewing a recent commit on this project, it appears they removed the default assumption of the file path for the UDUNITS_XML file (see commit here: 6b7c895)

I believe this was to make it work on multiple OS's, but I'm not an expert at generating wheels and the like.

You will have to manually export the path before running the pip install again. For me, the apt-get install libudunits2-dev version put the xml file at /usr/share/xml/udunits/udunits2.xml

You can find where it is installed on your system by just running a find command, find / -name udunits2.xml and then exporting the environment variable to wherever you locate the library, in my case export UDUNITS2_XML_PATH=/usr/share/xml/udunits/udunits2.xml and then run the pip install again.

If you don't find that file on your system, then you will need to install udunits2 (see UCAR's site on that if you aren't running Debian Linux, otherwise just copy my apt-get install from above; https://docs.unidata.ucar.edu/udunits/current/#Installation)

[bjlittle]

Hasn't this always been the case?

cf-units/setup.cfg

Lines 35 to 43 in cf4d66d

	[options]
	include_package_data = True
	install_requires =
	antlr4-python3-runtime ==4.7.2
	cftime >=1.2
	jinja2
	numpy
	# udunits2 cannot be installed with pip, and it is expected to be
	# installed separately.

True, but regardless of that, on the same rig where udunits2 is available on the system, cf-units installs for python 3.10 et al (see below), but not for 3.11.

So there is inconsistent behaviour here which I think we should investigate.

> conda create -n delme -c conda-forge python=3.10 pip
  ...
  <snip>

> conda activate delme

(delme)
> python --version
Python 3.10.10

(delme)
> pip --version
pip 23.1 from <snip>/lib/python3.10/site-packages/pip (python 3.10)

(delme)
> pip install cf-units
Collecting cf-units
  Using cached cf_units-3.1.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (529 kB)
Collecting antlr4-python3-runtime==4.7.2 (from cf-units)
  Using cached antlr4_python3_runtime-4.7.2-py3-none-any.whl
Collecting cftime>=1.2 (from cf-units)
  Using cached cftime-1.6.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.2 MB)
Collecting jinja2 (from cf-units)
  Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB)
Collecting numpy (from cf-units)
  Using cached numpy-1.24.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.3 MB)
Collecting MarkupSafe>=2.0 (from jinja2->cf-units)
  Using cached MarkupSafe-2.1.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (25 kB)
Installing collected packages: antlr4-python3-runtime, numpy, MarkupSafe, jinja2, cftime, cf-units
Successfully installed MarkupSafe-2.1.2 antlr4-python3-runtime-4.7.2 cf-units-3.1.1 cftime-1.6.2 jinja2-3.1.2 numpy-1.24.2

(delme) 
/net/home/h05/itwl/projects/git/geovista-slam
itwl@vld173:> python -c "import cf_units; print(cf_units.__version__)"
3.1.1

[bjlittle]

Also, wheels were never built for 3.11. Maybe it is just a matter of issuing a post release to make that happen?

Okay, yup. It's just a time-line thing @ocefpaf 👍

cf-units 3.1.1 was released on 12 Jul 2022, and python 3.11.x was release on 24 Oct 2022, see https://endoflife.date/python.

I guess if we push a post release, then the GHA should auto build and publish the binary wheel for python 3.11.x.

I'll crank the handle and see what happens 👍

[bjlittle]

A release of cf-units may help iris, see SciTools/iris#5226

[bjlittle]

Happy days 🥳

Closed by https://github.com/SciTools/cf-units/releases/tag/v3.2.0