Docker auto update

[TzurSoffer]

Auto update all deps on startup

[TzurSoffer]

This builds on the fix prior, only pay attention to the last commit. First two are the other pr

[Silverarmor]

1. Can you rebase the PR so only the relevant commits are present.
2. I don't think this is needed? We were discussing the GH action of publishing the docker image to docker hub.

   spotify-downloader/.github/workflows/docker-hub-image-publish.yml

   Lines 7 to 8 in f717baf

   	schedule:
   	- cron: "0 0 * * *"

[TzurSoffer]

1. Can you rebase the PR so only the relevant commits are present.
2. I don't think this is needed? We were discussing the GH action of publishing the docker image to docker hub.

   spotify-downloader/.github/workflows/docker-hub-image-publish.yml

   Lines 7 to 8 in f717baf

   	schedule:
   	- cron: "0 0 * * *"

Cant have one without the other, if you don't update the action, the deps will be outdated. Therefore, the library syncs itself. This also solves any dependency-related issues the user might get with time.

[Silverarmor]

Please resolve merge conflicts.

We can merge this, but this doesn't address the initial question I asked, of if we need to have the GH action run daily?

[TzurSoffer]

Please resolve merge conflicts.

We can merge this, but this doesn't address the initial question I asked, of if we need to have the GH action run daily?

Doing that rn. I think the action should only run when commits are added. For this to be possible without breaking the Docker, the dependencies need to be updated by the user

[TzurSoffer]

In my opinion, it should be updated by the user regardless to avoid issuees with time

[Silverarmor]

Ok, can you please update the GH action as you suggest?
Right now, it publishes a production build on github release, and a nightly build daily.
(With the manual workflow trigger as an option as well).

[TzurSoffer]

I think I did it, but I am unfamiliar with actions so please look over it

[Silverarmor]

Suggested change

- master

Let's not publish a docker hub image on push to master, and only create a production release when a GH release is published.

The below action would've failed as github.ref == 'refs/heads/master' isnt treated as a production build

[TzurSoffer]

Shouldn't the master branch be treated as the stable tag and the dev be the nightly? I don't know how GH action works, so I don't know how to do this, but that was my idea with this.

[Silverarmor]

Hmm.
Shouldn't docker images be immutable?
w/ this entrypoint, upgradding dependencies at runtime means:

• users require network access for every single command (compared to only at installation/build when dependencies r downloaded)
• The image is now non-reproducible over time, i.e. users with the same docker image can have different dependencies as they r resolved on startup
  • This is an issue since a dependency update could break an already published image (defeating the main purpose of the docker img?)

[TzurSoffer]

Hmm. Shouldn't docker images be immutable? w/ this entrypoint, upgradding dependencies at runtime means:

• users require network access for every single command (compared to only at installation/build when dependencies r downloaded)

• The image is now non-reproducible over time, i.e. users with the same docker image can have different dependencies as they r resolved on startup

  • This is an issue since a dependency update could break an already published image (defeating the main purpose of the docker img?)

1. Yes, this would have to update the deps every single time, a possible solution to this is to put the site-packages folder (or wtv uv uses) in a volume that is not a part of the image.
2. The idea that the image is non-reproducable is incorrect because all libraries will always be up to date, exactly like using the latest image, no matter what image is used. The dependencies will always be what is in the pyproject and, therefore the same thing in the GH action that will update every day.