Update Pipfile

[audiodude]

Make dependency versions more flexibile, and move pytest to dev dependencies.

[skyfenton]

Looks perfect

[jhanley634]

requests = "~=2.26"

It's possible that 2.32.3 is unsuitable for this project, in the sense that it causes a unit test to fail. But I am skeptical of that ...

Otherwise, LGTM.

[audiodude]

requests = "~=2.26"

It's possible that 2.32.3 is unsuitable for this project, in the sense that it causes a unit test to fail. But I am skeptical of that ...

Otherwise, LGTM.

Not sure what you mean. We barely have any unit tests, and certainly none that exercise requests.

[jhanley634]

requests = "~=2.26" ...

Not sure what you mean. We barely have any unit tests, and certainly none that exercise requests.

I mean it's unclear on what basis we would wish to stick to .26, given that .32 is current. It is usual to uprev to current deps when updating a pipfile, or to add a comment of e.g. "2.27 is known to break our code due to XXX". The recent debacle over sqlalchemy-mate would be a fair example of that. If the codebase offers no evidence that .27 and .28 are trouble for the project, such as Red unit tests, then updating to .32 would usually be appropriate. Put another way, a future maintainer may scratch their head, wondering "what undocumented trouble with .27 lay behind this commit?"

I have maintained code in more than a dozen projects where some deps remained frozen a couple years in the past while newly added deps were modern, and it isn't a pretty sight to debug. You wind up seeing novel version combinations which the upstream authors never saw and never tested against. Sometimes everything works together, but not always.

Unit tests give us the courage to refactor. Bumping the version up to .26 is a form of refactoring -- it changes the details while asserting that app-level behavior remains mostly the same. Unit tests let us measure what "the same" means, in a way that all team members can instantly agree upon.

---

There are some ruff --fix edits in the current PR. For future edits, consider creating a single-purpose PR containing the auto updates. This is similar to creating a single-purpose PR for automated items like "trim trailing whitespace". When all edits fit the same pattern, reviewers can quickly wrap their head around it and can quickly approve it.

---

LGTM, ship it as-is.

[audiodude]

requests = "~=2.26" ...

Not sure what you mean. We barely have any unit tests, and certainly none that exercise requests.

I mean it's unclear on what basis we would wish to stick to .26, given that .32 is current. It is usual to uprev to current deps when updating a pipfile, or to add a comment of e.g. "2.27 is known to break our code due to XXX". The recent debacle over sqlalchemy-mate would be a fair example of that. If the codebase offers no evidence that .27 and .28 are trouble for the project, such as Red unit tests, then updating to .32 would usually be appropriate. Put another way, a future maintainer may scratch their head, wondering "what undocumented trouble with .27 lay behind this commit?"

I don't think that's true at all. We are not "pinning" to .26, we don't have ==2.26. The syntax ~=2.26 means any minor version greater than or equal to .26, but less than 3.0.0. The lockfile will keep the dependencies as resolved at the time of installation so we don't have developers reporting bugs on versions that we can't track down, but otherwise when we add a new dependency the new version will potentially be installed.

I have maintained code in more than a dozen projects where some deps remained frozen a couple years in the past while newly added deps were modern, and it isn't a pretty sight to debug. You wind up seeing novel version combinations which the upstream authors never saw and never tested against. Sometimes everything works together, but not always.

Again, the version is not frozen, it's just the version present at the time the Pipfile was written. Later versions can be installed when the Pipfile is evaluated and the lockfile generated.

Unit tests give us the courage to refactor. Bumping the version up to .26 is a form of refactoring -- it changes the details while asserting that app-level behavior remains mostly the same. Unit tests let us measure what "the same" means, in a way that all team members can instantly agree upon.

There are some ruff --fix edits in the current PR. For future edits, consider creating a single-purpose PR containing the auto updates. This is similar to creating a single-purpose PR for automated items like "trim trailing whitespace". When all edits fit the same pattern, reviewers can quickly wrap their head around it and can quickly approve it.

These are from merging main, which recently got the ruff changes from the other PR. This is why I usually prefer "rebase and merge" over merge commits, so this doesn't happen.