Add missing dependencies to pyproject.toml

[altheaden]

Summary

This PR just adds the missing packages to the pyproject.toml that were mentioned in #14 (lxml and beautifulsoup4).
Objectives:

• Objective 1
• Objective 2
• ...
• Objective n

Issue resolution:

• Closes [Bug]: missing deps in pyproject.toml #14

Select one: This pull request is...

• a bug fix: increment the patch version
• a small improvement: increment the minor version
• a new feature: increment the minor version
• an incompatible (non-backwards compatible) API change: increment the major version

Please fill out either the "Small Change" or "Big Change" section (the latter includes the numbered subsections), and delete the other.

Small Change

• To merge, I will use "Squash and merge". That is, this change should be a single commit.
• Logic: I have visually inspected the entire pull request myself.
• Pre-commit checks: All the pre-commits checks have passed.

[altheaden]

@forsyth2 I wasn't sure what all was needed for the body of this PR so I've left the Objectives list empty, since it's such a small change.

[forsyth2]

Thanks @altheaden!

@xylar I'm a still a little unclear why we have both pyproject.toml and conda/dev.yml. I see a little discussion about it on #1.

From Claude:

You don't necessarily need both. Here are common scenarios:

• Conda-first approach: Use conda/dev.yaml for everything, including pip packages in the pip section
• pip-first approach: Use pyproject.toml for Python dependencies and project config
• Hybrid approach: Use conda/dev.yaml for system dependencies and environment setup, pyproject.toml for Python package metadata and pip dependencies

The hybrid approach is common when you need system libraries that are easier to install via Conda (like CUDA, scientific libraries) but want to maintain standard Python packaging practices with pyproject.toml.
If you use both, you'll typically want to avoid duplicating Python package dependencies to prevent version conflicts.

There definitely is duplication.

https://github.com/E3SM-Project/zppy-interfaces/blob/main/conda/dev.yml:

  # Base
  # =================
  - beautifulsoup4
  - lxml
  - matplotlib-base >=3.8.2,<3.10
  - mpas_tools >=0.21.0
  - netcdf4
  - numpy >=2.0,<3.0
  - output_viewer=1.3.3
  - xarray >=2023.02.0
  - xcdat >=0.7.3,<1.0

https://github.com/E3SM-Project/zppy-interfaces/blob/main/pyproject.toml (on main):

dependencies = [
    "matplotlib >=3.8.2,<3.10",
    "netcdf4",
    "numpy >=2.0,<3.0",
    "xarray >=2023.02.0",
    "xcdat >=0.7.3,<1.0",
]

[xylar]

@forsyth2 we need the pyproject.toml to make this a python package. But the pyproject.toml wouldn't necessarily have to include the dependencies. Those dependencies that it does include have to be available on PyPI (installable via pip). So that's why we can't include mpas_tools and output_viewer (which are only available on conda-forge).

The pyproject.toml could define a development environment for installing packages from PyPI but it can't define a conda environment. Since we use conda environments for development, we need conda/dev.yml for that purpose.

It's still handy to include as many dependencies in pyproject.toml as we can. This allows us to run pip check as part of testing (on conda-forge for sure and hopefully locally in CI as well). pip check can tell us if the environment has packages in it that violate the specs in pyproject.toml not just from zppy-interfaces but also from all of the pyproject.toml (or equivalent) files in all the other installed conda packages. There is no conda equivalent of this tool so it's a good idea to take advantage of this capability as much as we can.

So Claude's answer doesn't really cover why we have both and want to keep them synced up. That's why.

[forsyth2]

Great, thanks for the added context @xylar! I'll merge.