fix: package name

[steveoh]

In the future, PyPI will require all newly uploaded source distribution filenames to comply with PEP 625. Any source distributions already uploaded will remain in place as-is and do not need to be updated.

Specifically, your recent upload of 'ugrc-sweeper-2.0.3.tar.gz' is incompatible with PEP 625 because it does not contain the normalized project name 'ugrc_sweeper'.

In most cases, this can be resolved by upgrading the version of your build tooling to a later version that supports PEP 625 and produces compliant filenames.

I'm not sure if this pr is a resolution or not but I think it may be?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 22.38%. Comparing base (69ba690) to head (d2bdd46).
Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #130   +/-   ##
=======================================
  Coverage   22.38%   22.38%           
=======================================
  Files          13       13           
  Lines         746      746           
  Branches      132      132           
=======================================
  Hits          167      167           
  Misses        574      574           
  Partials        5        5           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stdavis]

Do we really want to change the name of the package? This will change the name of the package in pypi, correct? We have several other python packages with hyphens in the name. I wonder if the python version bump is the fix here and we should try leaving the name alone. My reading of PEP 625 makes me think that the problem is the filename of the distribution file, not necessarily the package name.

[steveoh]

It wasn't clear to me if this would change the pypi package name or the artifacts of the build.

I'm not sure what you mean by the version bump. If we don't change the name we probably need to replace https://github.com/agrc/sweeper/blob/fix/pep-625/.github/workflows/push.yml#L61 with something else. I'm seeing people use twine.

[stdavis]

I'm not sure what you mean by the version bump.

I meant the python version bump in .python-version. I'm assuming that the newer sdist command in v3.11 correlates with this:

In most cases, this can be resolved by upgrading the version of your build tooling to a later version that supports PEP 625 and produces compliant filenames.

I've used twine before and it seemed nice. I don't remember why we didn't standardize on it. Perhaps we never really considered it.

[steveoh]

That's a good idea.

[stdavis]

I'm good with giving this a try. But I'd love to hear what @jacobdadams thinks...

[steveoh]

from https://setuptools.pypa.io/en/latest/deprecated/commands.html

While it is perfectly fine that users write setup.py files to configure a package build (e.g. to specify binary extensions or customize commands), on recent versions of setuptools, running python setup.py directly as a script is considered deprecated.

and https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

hatchling seems like something to evaluate if we do need something to handle our c/c++ deps. Thinking anything in arcpy, database stuff (pgsql, sqlalchemy, oracle), gdal things etc.

[steveoh]

This has the latest and greatest from supervisor so it should correct the publishing package name and follow the best practices for ci. It's ready for another review. Thanks!