Update Bazel Dependencies #783

Activity

1. MaximilianSoerenPollak

   added the

   Task

   issue type on Sep 1, 2026
2. MaximilianSoerenPollak

   added

   good first issueGood for newcomersGood for newcomers

   on Sep 1, 2026
3. github-project-automation

   added this to INF - Infrastructure Communityon Sep 1, 2026
4. AlexanderLanin commented on Sep 1, 2026

   

   AlexanderLanin

   on Sep 1, 2026

   Member

   More actions

   we cannot update bazel modules without demand that easily, as they are enforced by bazel to all score users (which use bazel)
5. AlexanderLanin

   removed

   good first issueGood for newcomersGood for newcomers

   on Sep 28, 2026
6. AlexanderLanin

   moved this to refinement needed in INF - Infrastructure Communityon Sep 28, 2026
7. AlexanderLanin commented on Oct 6, 2026

   

   AlexanderLanin

   on Oct 6, 2026

   Member

   More actions

   @LittleHuba @umaucher do you have any guidance what can / should / must / must-not be updated? As those bazel_dep are propagated. If we stay on old versions, we cannot guarantee compatibility with the new versions and vice versa.

   I'm happy to move this to some meeting as well - whichever one you would like 😆
8. umaucher commented on Oct 7, 2026

   

   umaucher

   on Oct 7, 2026

   Contributor

   More actions

   I think the tricky question / problem is here where / how it is used so from a persistency point of view if we stay with the example aspect_rules_py it is only a "implicit" dependency:

   ✔ ~/Projects/git/eclipse-score/persistency [main] 
   $ bazel mod all_paths aspect_rules_py
   <root> (score_persistency@_)
   ├───score_docs_as_code@8.3.0 
   │   └───aspect_rules_py@1.4.0 # 
   ├───score_tooling@2.3.1 
   │   └───aspect_rules_py@1.4.0 # 
   └───score_tools@_ 
       └───aspect_rules_py@1.4.0 #
   

   but if one of it wants to update it needs to be compatible to all the others since bazel would use "the highest" version in the tree. So maybe updates like this needs to be tested / challenged in the reference integration still most likely tricky to identify all runtime issues? So far in persistency we tried to stay up2date with all deps we defined in our MODULE.bazel but I think this is getting more and more tricky the more "consumers / users" you have.
9. umaucher commented on Oct 7, 2026

   

   umaucher

   on Oct 7, 2026

   Contributor

   More actions

   another discussion IMHO never got really solved is what should be dev_dependencies and what not ... not thought threw but as a brainstorming e.g.

   • why not having "splitted" modules (score_persistency_impl, score_presistency_docs, score_persistency_tests) otherwise always all the needs for the different topics are implicit injected
   • the provider "defines" the dependencies. See for example the discussion in Need for additional dependencies when using score_tooling tooling#82 (comment)
10. umaucher commented on Oct 7, 2026

    

    umaucher

    on Oct 7, 2026

    Contributor

    More actions

    where it is getting really really ugly 🤯 : baselibs has a dependency to score_bazel_cpp_toolchains 1.0.4 which is "incompatible" with rules_cc > 0.2.17 so if baselibs updates googletest to 1.18.0 it inherits a "later" rules_cc via:

    ├───googletest@1.18.0 
    │   ├───abseil-cpp@20260526.0 
    │   │   └───rules_cc@0.2.18 # 
    
11. LittleHuba commented on Oct 7, 2026

    

    LittleHuba

    on Oct 7, 2026

    Last edited by LittleHuba

    More actions

    @LittleHuba @umaucher do you have any guidance what can / should / must / must-not be updated? As those bazel_dep are propagated. If we stay on old versions, we cannot guarantee compatibility with the new versions and vice versa.

    I'm happy to move this to some meeting as well - whichever one you would like 😆

    Update dev-dependencies whenever you think it helps you (no impact on users of the module).
    Update other dependencies only when you need a feature/fix from a later version (Any bump forces all your users to bump to this version or a later one as well).
    To ensure compatibility, best use a dependency version checker as we have in communication module. (see workflows there)
12. AlexanderLanin commented on Oct 8, 2026

    

    AlexanderLanin

    on Oct 8, 2026

    Member

    More actions

    @LittleHuba thats an interesting approach, will defintely see how to adopt it! It doesn't quite solve the original question, e.g. we need to update rules_python which will NOT lead to any problems within score, but AFAIK it leads to problems for BMW. According to what you wrote I should just update it, as I need it. But this doesn't quite match reality, does it? Simplest idea would be: if you update a dependency to a new "highest version" within score, then bring that "request" into the alignment meeting. Its not the best approach, but anything is better than pure chaos.