Update pyproj to 3.7.2

[pyup-bot]

This PR updates pyproj from 2.3.1 to 3.7.2.

Changelog

3.7.2

The `T` flag in the `ln` command ensures that "stable" is treated as a file,
and not as a directory to create the symbolic link inside of. The `-n` flag
on `git commit` is needed if you had previously installed `pre-commit` as the
`gh-pages` branch does not have a pre-commit config and pre-commit will fail.
The `-n` flag skips pre-commit checks.

Preparing for the next release

To put the repository in a state for the next release cycle:

1. Edit `docs/history.rst`.
2. Add a new "Latest" section header to the top of the version list.
3. Edit `docs/past_versions.rst` and add the recent release. For example:


- `3.7.0 <https://pyproj4.github.io/pyproj/3.7.0/>`_

3.7.2rc0

This creates a lightweight git tag.

Push the tag to github with:

bash
git push --follow-tags


Create a GitHub Release

1. Go to https://github.com/pyproj4/pyproj/releases.
2. Click "Draft a new release".
a. Click "Select tag" and either:
b. Select the release candidate tag you pushed from the command line.
3. Type the version tag you would like GitHub to create as part of this release (ex. `3.7.2rc0`).
4. Enter "X.Y.Zrc0" as the Release title using the version number you created.
5. Leave the description blank.
6. Check the box for "Set as a pre-release".
7. Check the box for "Create a discussion for this release".
8. Click "Publish release".

Test the release builds

1. Check the wheels built under GitHub Actions
[here](https://github.com/pyproj4/pyproj/actions/workflows/release.yaml).
2. Verify wheel and sdist upload to PyPI at
https://pypi.org/project/pyproj/X.Y.Zrc0/#files modifying the X.Y.Z for your release.
3. Update the release discussion (see below section)
4. Create a draft PR at https://github.com/conda-forge/pyproj-feedstock and verify tests pass (see below section).
5. Verify Debian builds were successful on the release discussion.
6. Verify Fedora builds were successful on the release discussion.
7. Verify the docs build successfully.

Update release discussion

The GitHub release process above created a discussion at
https://github.com/pyproj4/pyproj/discussions/. Find that discussion
and update the post with information about what builds to check:


Release Candidate 0 Status:

- [ ] Conda Forge
- [ ] Debian: https://buildd.debian.org/status/package.php?p=python-pyproj&suite=experimental
- [ ] Fedora

Thanks for any testing that you can do.


See previous release candidate discussions for debian and fedora package
maintainers to mention for help.

Create a draft conda-forge PR

The instructions below assume you:

1. Have an existing local conda environment with the `conda-smithy` package
installed and updated.
2. You have a personal fork of the
https://github.com/conda-forge/pyproj-feedstock repository on GitHub.
3. You have a local updated clone of the conda-forge feedstock repository and
a git remote for your fork.

To create a feedstock pull request to test the release candidate:

1. Create a new branch for the PR based on the main branch:

bash
git checkout main
git checkout -b dep-372


2. In a browser, go to
https://pypi.org/project/pyproj/3.7.2rc0/#pyproj-3.7.2rc0.tar.gz but
for the version you're releasing and copy the SHA256.
3. Edit `recipe/meta.yaml` and update the version number and the SHA256.
Make sure to reset the build number to 0 and update any dependencies
if necessary.
4. Add and commit these updates:

bash
git add recipe/meta.yaml
git commit -m "Update version to 3.7.2rc0"


5. Rerender the feedstock with conda-smithy:

bash
conda smithy regenerate -c auto


6. Push the changes to your fork's remote.

bash
git push -u <your_fork>


7. Go to https://github.com/conda-forge/pyproj-feedstock and create a **draft**
pull draft request with your new branch.

8. Do **NOT** merge the pull request. It will be updated during the final release process.

Phase 2: Make the release

After the candidate has proven itself, it will be promoted to a final release.

Remove the rc postfix

Remove the `rc` postfix from the the version number `__version__` in `__init__.py` (ex. `3.7.2rc0` -> `3.7.2`).

Create a tag on the repository

The next step is to create a tag with the name `<major>.<minor>.<patch>`. This can be done using the git command line or
as part of the GitHub release. For example:

3.7.1.dev0

5. Commit and push these changes to `main`.

Links

• PyPI: https://pypi.org/project/pyproj
• Changelog: https://data.safetycli.com/changelogs/pyproj/
• Repo: https://github.com/pyproj4/pyproj