Version 0.2: Bump all versions to 0.2 #416
Conversation
ErikDeSmedt
force-pushed
the
20240426_release_0_2
branch
4 times, most recently
from
c2cb447
to
18a8414
Compare
| @@ -14,13 +14,14 @@ python = "^3.8" | |||
| click = "^8" | |||
| grpcio = "^1" | |||
| protobuf = "^5" | |||
| gl-client = { path = "../../libs/gl-client-py", develop = false} | |||
| gl-client = "0.2.0" | |||
There was a problem hiding this comment.
Are we going to publish glcli with 0.2? If it is not already published I would rather prefer to postpone a cli tool release until we have a rust version of glcli and keep it as a developer tool until then.
There was a problem hiding this comment.
I am not a python expert so I have a few questions:
-
Can you elaborate a bit on why you prefer to remove the lockfile on cln-version-manager?
-
Can removing the lockfile from the cln-version-manager break the CI if there are updates to upstream libs that are e.g. not semver compatible?
-
Can removing the lockfile result in local breakage during development (same way as CI for example but through gl-testing)?
|
Let me try to see if I can add rationales to the changes here:
The usual suggestion would be for libraries to not have a lock file, and scripts and tools that are likely to be installed as standalone tools, to specify a lock file. This is because libraries will be combined with other libraries and tools as a dependency, and if the lock files are too strict (which they are almost guaranteed to be since only single versions can be locked to) then the resolver of the dependee may not be able to find a solution for them, failing the install. Standalone tools are on the other side of the spectrum, being standalone, if we can write a lock file, that lock file should also be valid for a user installation, and can considerably speed up the installation, and prevent untested version combinations. As for CLNVM, it is a standalone tool, but only used in other projects where we may have other dependencies that could clash with CLNVM's lock file, hence we likely don't want to be too pedantic with it.
That's exactly the risk, however breakage in CI is preferable over breakage on a user device, as the latter is harder to debug, and gives users a bad experience that can be offputting.
That's what we have the top-level lock files for: they subsume CLNVM, gl-testing and all of their combined transitive dependencies, and as such there is no leeway for CI and dev setups to chose, resulting in reproducible issues (assuming the deb setup has not drifted of course). |
This is a commit which prepares us to launch version `0.2`. I've chosen to pin `gl-testing` to an exact version of `gl-client`. This approach is feasible because we maintain both packages and can update them in lock-step
I prefer to have it this way. Yes, removing the lock-file make the builds less reproducible. But our end-users who `pip install cln-version-manager` won't have a reproducible installation anyway. If issues occur, I want to be the first to notice.
Fixed the dependency from `glcli` to `gl-client`. I've used a fixed version number. This is often recommended for packages that are released on lock-step. This ensures we never have any version conflict between `glcli` and `gl-client`.
cdecker
force-pushed
the
20240426_release_0_2
branch
from
9a64a47
to
60f323a
Compare
This is a commit which prepares us to launch version
0.2.