This message was deleted.
# dependency-managements
Slackbot
03/28/2022, 9:19 PMThis message was deleted.
s
Sam Edwards
03/28/2022, 9:21 PMJust basic locking for a single configuration.
v
Vampire
03/28/2022, 9:42 PMMaybe dependency verification is more what you'd like?
👍 1
s
Sam Edwards
03/28/2022, 10:21 PMMaybe that's a better name for it?
I just seen a lot of real world situations where versions get bumped some people don't realize it. This would give visibility into that and check into source control this baseline file. I created a Gradle plugin that does this for modules and artifacts and dependency trees.
Sam Edwards
03/28/2022, 10:22 PMhttps://github.com/Kotlin/binary-compatibility-validator
Library inspired me with the ability to create a baseline and check against it.
The goal of that library is to prevent public API changes
Sam Edwards
03/28/2022, 10:27 PMI haven't published the work I've done probably yet. But will if it's a value.
Sam Edwards
03/28/2022, 10:47 PMI just talked to @Zak Taccardi about it. Potentially could leverage the lock file format, but still provide the functionality I've described.
v
Vampire
03/29/2022, 1:57 AMNo, not a better name. A different Gradle feature. You have a metadata file where you have the checksums for all dependencies. If a checksums is not correct, you get an error. This is to prevent corrupted or infected dependencies. But you also get a clear complaint if a checksum is not present, which is exactly the part you want I think.
s
Sam Edwards
03/29/2022, 11:43 AMI made a more complete description of the functionality I'm looking for here: https://gradle-community.slack.com/archives/CAH4ZP3GX/p1648518134919579
v
Vampire
03/29/2022, 12:16 PMI still think that the dependency verification feature would be sufficient for your needs and additionally protect against corrupt or infected libs.
s
Sam Edwards
03/29/2022, 4:09 PMThat would definitely be helpful. While protecting against correct or infected libs is very critical, this use case is more just surfacing version changes, additions and removals.
So, when I bump Kotlin from 1.5.31 -> 1.6.10, it tells me:
- org.jetbrains.kotlinkotlin stdlib1.5.31
+ org.jetbrains.kotlinkotlin stdlib1.6.10
Then I would need to re-baseline in order to accept that change, otherwise the build fails.
Goal: Make any changes to resolved dependencies caught, have a developer choose to accept/baseline it, and then have a history in Git via the tracking file.
v
Vampire
03/29/2022, 5:06 PMYes, and all that and more you get with dependency verification. How often do I have to repeat that?
Vampire
03/29/2022, 5:07 PMOr well, you wouldn't see removals. But changes and additions as for those no checksum would be present in the versioned file and thus the build would fail.
Vampire
03/29/2022, 5:08 PMDon't get me wrong.
If you want to reinvent the wheel in your own plugin, be welcome to do so.
You just asked whether the functionality is there already and seem to forcibly refuse to listen to the answer.
s
Sam Edwards
03/29/2022, 5:23 PMA lot of this is new to me, so I didn't realize you were referring to an existing feature of "dependency verification".
Thank you so much for your answers. I'm sorry I've been unable to understand yet. I'll try out dependency verification and see if I can create the behavior you have called out.
Again, thank you. Sorry, I am blindly learning all this, and honestly been a bit stubborn, so I apologize for that.
v
Vampire
03/29/2022, 5:43 PMDon't worry. 🙂
❤️ 1
7 Views