gilesknap / gphotos-sync

Google Photos and Albums backup with Google Photos Library API
Apache License 2.0
1.97k stars 161 forks source link

Not working after upgrade to Python 3.12 & gphotos-sync 3.2 #462

Closed rmancuso40 closed 5 months ago

rmancuso40 commented 6 months ago

I upgraded my python and gphotos-sync environment and now I get "gphotos-sync: error: unrecognized arguments: --log-level info --skip-albums --start-date 2023-12-17" when I run my backup script. If I run "gphotos-sync --help", the only options show are:

usage: gphotos-sync [-h] [--version]

options: -h, --help show this help message and exit --version show program's version number and exit

I checked what I could for my install and everything looks ok. Everything was working fine with Python 3.11 and gphotos-sync 3.12. Any suggestions?

I downgraded back to Python 3.11.7 and gphotos-sync 3.1.3 and everything works again

donwlewis commented 6 months ago

Also seeing this issue when running in a container:

usage: gphotos-sync [-h] [--version]
gphotos-sync: error: unrecognized arguments: /storage
ivan68ivan commented 6 months ago

Python 3.11.6 & gphotos-sync 3.2 --> same error

I downgrade gphotos-sync to 3.1.3 --> all OK

gilesknap commented 6 months ago

OK this sounds bad. will try to take a look ASAP

goose-ws commented 6 months ago

+1 for affected on 3.2, rolling back to 3.1.3 for now.

gilesknap commented 5 months ago

@rmancuso40 @donwlewis @ivan68ivan @goose-ws I believe this is all fixed in v3.2.1

Also the container image is published to Dockerhub as well as GHCR.

goose-ws commented 5 months ago

Can confirm that 3.2.1 works for me. Thanks for the quick turnaround!

Edit: Although using the :latest tag gives me the same error. Not sure which build that is, but I'll stick to :3.2.1 for now.

gilesknap commented 5 months ago

@goose-ws, sorry about that, I don't think I publish a latest anymore. But there is still one there.

I need to delete that or start publishing :latest again.

Most of my projects at work do not publish a latest because explicit versions are a good idea, but I could be persuaded that this is fine for a photo backup tool.

f1sherman commented 5 months ago

@gilesknap I think it's acceptable to have a latest here unless you're publishing a lot of breaking changes. Also, it's something a lot of people expect and some folks are already using it (like me :)).

gilesknap commented 5 months ago

@f1sherman, agreed, I'll update the CI this weekend.

gilesknap commented 5 months ago

@goose-ws I've checked and I am publishing latest along with the version tag so I get:

(skeleton-merge) [giles@ws1 gphotos-sync]$ docker run gilesknap/gphotos-sync:latest --version
Unable to find image 'gilesknap/gphotos-sync:latest' locally
latest: Pulling from gilesknap/gphotos-sync
Digest: sha256:a0a0a8357caa94ddb182242de878ad4a2920d38f29525d26d17776e60c4f17fc
Status: Downloaded newer image for gilesknap/gphotos-sync:latest
3.2.1
(skeleton-merge) [giles@ws1 gphotos-sync]$ 

I'm wondering if you already had :latest in your cache? This is indeed a pitfall with using the latest tag!!

You can get around that with this command

docker run --pull always gilesknap/gphotos-sync --version
gilesknap commented 5 months ago

I think we can close this now.