Relax pytz requirement? about utt

[larose]

poetry.lock needs to be updated for sure. I'll take a deeper look at it this weekend.

[larose]

Absolutely, do you want to create a PR?

[privong]

Sure, I can do that.

Was there a specific reason for tying pytz to the 2019.3 version or was that just the most recent version available when the project was migrated to Poetry? I'm wondering if it needs to be "2019.3 or a more recent version" or if any version of pytz is effectively acceptable. At quick glance I don't see anything in the code that obviously requires a specific version.

[larose]

There was no reason except it was the most recent version available at the time.

I think any versions of pytz would work. But I usually prefer to pin dependencies to a specific version, so what is tested in the CI is exactly what is used by the users, so there are no surprises.

However, I don't think python handles having multiple versions of the same package. So if another package installed on a utt user's machine requires a specific version for pytz that is different than the one required by utt, I think either utt or the other package won't be installable. So we want to specify a min version only on pytz (or any other dependencies), instead of a specific version.

How did you notice the issue on your machine? Did utt stop working, or worked but with a warning?

[privong]

utt continues to work fine, but I haven't been able to update utt past v1.22 (because I have pytz installed via an OS package and pytz was upgraded to 2020.1 in early May).

I can install utt in my home directory, and have been able to install the latest there (by having a home directory install of pytz) but I prefer to avoid having several sets of the same python packages installed, for my own sanity :)

I don't know how often other distros update their pytz packages. Arch tends to be pretty bleeding edge. So I could imagine pinning utt's dependency to 2020.1 might inadvertently cause headaches for other users whose distros may not have updated the package yet. So specifying a minimum version of 2019.3 may be the best way to go (since no one has otherwise opened an Issue about having an even older version of pytz).

I haven't personally done much with pytz, but my impression is that new releases are TZ database upgrades and don't have API changes. So specifying a minimum version might be low-risk.

[larose]

Perfect, thanks.

So specifying a minimum version of 2019.3 may be the best way to go

Sounds good 👍

[privong]

Testing now, aiming to do a PR later today

[privong]

The poetry dependency management seemingly complicates this a bit. Changing the pytz version spec in the pyproject.toml file means it's out of sync with the poetry.lock file. So I need to run poetry update, which seems to result in changes most of the dependencies (since the newest available versions are different from what was committed).

This is my first experience with poetry, so I'm not sure what's essential, best practice, etc.

I think I can commit just the pytz version change into pyproject.toml file and leave the poetry.lock file (since the latter is mainly used for coordinating deps among devs?). Is my line of thinking correct on that?

[larose]

This has been fixed in 1.27 (PR: #85).

I updated pyproject.toml and then ran poetry update pytz.

[privong]

Great. Thanks @larose!