posthog
posthog copied to clipboard
PostHog
chore(deps): Move all deps to compatible releases
Problem
Our current use of == for specifying dependencies in requirements.in files with pip-tools locks us into specific versions. This strict versioning approach can lead to dependency conflicts when integrating with other libraries or projects and hampers our ability to receive bug fixes and minor feature updates that follow semantic versioning. Adapting our requirements to be more flexible will facilitate easier updates and maintenance of our codebase, benefiting our developers and aligning with best practices for Python project management.
Changes
We should update our dependency specifications in requirements.in files from using == to ~=. This change aims to leverage the compatibility operator ~= to specify minimum versions while allowing minor updates. For example, changing xyz==1.1.2 to xyz~=1.1.2 means we accept any version 1.1.? and less than 1.2.0, embracing backward-compatible changes. This transition supports better dependency management by allowing us to stay up-to-date with the latest patches and minor releases, potentially including important security patches and performance improvements, without manually updating each dependency for minor versions.
How did you test this code?
- rely on tests
- hobby deploy
This updates to patch releases... but also some major versions for sub-dependencies... Should be fine? 🙈
This is slightly scary to me, because it can make things fragile too 😅
(1) We need to ensure all library dependencies follow semantic versioning
(2) If I understand things correctly, this can make things break for the first time in production. Consider: (a) A dependency releases a breaking change / a change we implicitly depend on that's broken now, with a minor version release (b) We start a new deploy for something unrelated, docker container refreshes dependencies, we install this new minor version (c) Things break in production, bring pods down, while dev / local running old version is fine.
Is there a way to combat (2) ?
Most of these concerns are addressed by the fact that we do have lockfile. This here does not change the lockfile to be more liberal.
if they change a requirement, it could change a bunch of others as well
That's not the intention. Pip-compile does not update unrelated dependencies merely because you've updated another dependency. For this PR here, I've manually used the update flag to pull all dependencies to their latest allowed versions. This let's us quickly see where a patch update is available.
We need to ensure all library dependencies follow semantic versioning
Most libraries do follow that. Should we see one that doesn't, we can remove the operator for it.
docker container refreshes dependencies, we install this new minor version
This is something that cannot happen due to the versions being locked in requirements.txt and the full set always being tested. Everything installs from the requirements.txt.
What then is it good for? Well, it's just a tiny change but
- does make updating all things to latest patch easier
- dependabot can give us patch PRs and doesn't need to touch the version in manifest
- lower chance of incompatibilities because on dependency requires a specific patch of another, in that case it would upgrade it
My bad, I missed that requirements.txt still locks to specific versions, and it's only the .in file; which I guess does de-risk things quite a bit, and makes (2) obsolete. Nice 👍 , and requirements.txt will only update when we manually run pip-compile, and whenever we do that, we can extensively test for anything that breaks and any libs that bork, this just makes it easier to know which compatible versions to upgrade to?
(are the bits of formatting to do with the version bumps or just fly-by? would be neater to split them if they're unrelated - PRs are mostly free 🤣)
I think because ruff went from ruff==0.1.2 to ruff==0.2.1. (and it's one of the few where we just have > operator 🙃 )
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.
This PR was closed due to lack of activity. Feel free to reopen if it's still relevant.