Version catalog doesn't suggest updates to dependencies delcared in settings.gradle [226078451]

Obsolete

Feature Request

Status Update

No update yet.

Description

gr...@zimmerbiomet.com

created issue #1

Mar 22, 2022 08:43PM

DESCRIBE THE ISSUE IN DETAIL:

STEPS TO REPRODUCE:

Use a version catalog in settings.gradle
Declare dependencies the same as or similar to

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            version('compose_version', '1.0.5')
            library('compose-ui', 'androidx.compose.ui', 'ui').versionRef('compose_version')
            library('compose-foundation', 'androidx.compose.foundation:foundation:1.0.5')
            bundle('compose', ['compose-ui', 'compose-foundation'])
        }
    }
}

In app build.gradle Add

    implementation libs.bundles.compose

   implementation libs.compose.ui
   implementation libs.compose.foundation

Observe that neither in settings.gradle or build.gradle does Android Studio suggest updating those out-of-date versions

ATTACH SCREENSHOTS/RECORDINGS OF THE ISSUE

ATTACH LOG FILES (Select Help > Show Log in Files, or Show Log in Finder on a Mac)

IMPORTANT: Please read https://developer.android.com/studio/report-bugs.html carefully and supply all required information.

Studio Build:

Android Studio Bumblebee | 2021.1.1 Patch 2
Build #AI-211.7628.21.2111.8193401, built on February 16, 2022
Runtime version: 11.0.11+0-b60-7590822 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 10.15.7
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 12
Registry: external.system.auto.import.disabled=true
Non-Bundled Plugins: com.intellij.marketplace (211.7628.36), com.thoughtworks.gauge (211.6693.111), org.jetbrains.kotlin (211-1.6.10-release-923-AS7442.40), org.intellij.plugins.markdown (211.7142.37)

Version of Gradle Plugin: 7.1.2 Version of Gradle: 7.4.1 Version of Java: 11 OS: MacOs 10.15.7

Comments

di...@google.com <di...@google.com> Mar 23, 2022 09:50AM

Assigned to an...@google.com.

je...@google.com <je...@google.com> Mar 27, 2022 09:22PM

Reassigned to xo...@google.com.

ma...@outdoorsy.co <ma...@outdoorsy.co> #2Jul 11, 2022 06:29PM

datastore-core and datastore-preferences have dependencies on android for SharedPreferencesMigrations and convenience constructors. We should extract these dependencies so users can use this in kotlin-only parts of their code.

ta...@gmail.com <ta...@gmail.com> #3Oct 7, 2022 03:44PM

Would this enable Kotlin Multiplatform usage? Or just Kotlin/JVM in non-Android settings?

xo...@google.com <xo...@google.com> #4Oct 7, 2022 03:50PM

Reassigned to al...@google.com.

This work is intended to support kotlin-only modules in android projects using Kotlin/JVM. We haven't tested this in non-android settings and haven't built it using Kotlin Multiplatform.

gr...@zimmerbiomet.com <gr...@zimmerbiomet.com> #5Oct 7, 2022 03:58PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit c9bbc6f26740be8b2ca486032238442e1138c914
Author: rohitsat13 <rohitsat@google.com>
Date: Tue Sep 29 09:36:28 2020

Split out datastore and datastore-core modules

Test: Ran all datastore tests
Bug: 168512698
Relnote: Created a pure kotlin dependency for datastore to allow for faster compilation
Change-Id: I42d75d0f66dc0cac19bd0f452a84b58806a65a46

M buildSrc/src/main/kotlin/androidx/build/PublishDocsRules.kt
A datastore/datastore-core/api/1.0.0-alpha01.txt
M datastore/datastore-core/api/current.txt
A datastore/datastore-core/api/public_plus_experimental_1.0.0-alpha01.txt
M datastore/datastore-core/api/public_plus_experimental_current.txt
A datastore/datastore-core/api/restricted_1.0.0-alpha01.txt
M datastore/datastore-core/api/restricted_current.txt
M datastore/datastore-core/build.gradle
D datastore/datastore-core/lint-baseline.xml
M datastore/datastore-core/src/main/java/androidx/datastore/core/CorruptionHandler.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/DataMigration.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/DataMigrationInitializer.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/DataStore.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/DataStoreFactory.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/InitializerApi.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/Serializer.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/SingleProcessDataStore.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/handlers/NoOpCorruptionHandler.kt
M datastore/datastore-core/src/main/java/androidx/datastore/core/handlers/ReplaceFileCorruptionHandler.kt
M datastore/datastore-core/src/test/java/androidx/datastore/core/DataMigrationInitializerTest.kt
M datastore/datastore-core/src/test/java/androidx/datastore/core/DataStoreFactoryTest.kt
M datastore/datastore-core/src/test/java/androidx/datastore/core/SingleProcessDataStoreTest.kt
M datastore/datastore-core/src/test/java/androidx/datastore/core/TestingSerializer.kt
M datastore/datastore-core/src/test/java/androidx/datastore/core/handlers/ReplaceFileCorruptionHandlerTest.kt
M datastore/datastore-preferences/api/api_lint.ignore
M datastore/datastore-preferences/api/current.txt
M datastore/datastore-preferences/api/public_plus_experimental_current.txt
M datastore/datastore-preferences/api/restricted_current.txt
M datastore/datastore-preferences/build.gradle
M datastore/datastore-preferences/datastore-preferences-proto/src/main/java/androidx/datastore/preferences/PreferencesMapCompat.kt
M datastore/datastore-preferences/src/androidTest/java/androidx/datastore/preferences/PreferenceDataStoreFactoryTest.kt
M datastore/datastore-preferences/src/androidTest/java/androidx/datastore/preferences/SharedPreferencesToPreferencesTest.kt
M datastore/datastore-preferences/src/main/java/androidx/datastore/preferences/PreferenceDataStoreFactory.kt
M datastore/datastore-preferences/src/main/java/androidx/datastore/preferences/Preferences.kt
M datastore/datastore-preferences/src/main/java/androidx/datastore/preferences/PreferencesSerializer.kt
M datastore/datastore-preferences/src/test/java/androidx/datastore/preferences/PreferencesSerializerTest.kt
M datastore/datastore-proto/src/main/java/androidx/datastore/protos/ProtoSerializer.kt
M datastore/datastore-proto/src/test/java/androidx/datastore/protos/ProtoSerializerTest.kt
M datastore/datastore-sampleapp/build.gradle
M datastore/datastore-sampleapp/src/main/java/com/example/datastoresampleapp/PreferencesDataStoreActivity.kt
M datastore/datastore-sampleapp/src/main/java/com/example/datastoresampleapp/ProtoDataStoreActivity.kt
M datastore/datastore-sampleapp/src/main/java/com/example/datastoresampleapp/SettingsFragment.kt
M datastore/datastore/api/api_lint.ignore
A datastore/datastore/api/current.txt
A datastore/datastore/api/public_plus_experimental_current.txt
A datastore/datastore/api/res-current.txt
A datastore/datastore/api/restricted_current.txt
A datastore/datastore/build.gradle
M datastore/datastore/src/androidTest/AndroidManifest.xml
A datastore/datastore/src/androidTest/java/androidx/datastore/DataStoreFactoryTest.kt
M datastore/datastore/src/androidTest/java/androidx/datastore/TestingSerializer.kt
M datastore/datastore/src/androidTest/java/androidx/datastore/migrations/SharedPreferencesMigrationTest.kt
M datastore/datastore/src/main/AndroidManifest.xml
A datastore/datastore/src/main/java/androidx/datastore/DataStoreFactory.kt
M datastore/datastore/src/main/java/androidx/datastore/migrations/SharedPreferencesMigration.kt
M settings.gradle

https://android-review.googlesource.com/1441928

re...@gmail.com <re...@gmail.com> #6Jan 18, 2023 02:30AM

This should be available in the next release.

xo...@google.com <xo...@google.com> #7Jan 24, 2023 01:15PM

Hi! I'm pleased to say that yes, there is progress: all being well, lint (both at the command-line and in its IDE integration, with the yellow highlighting) will be detecting dependencies for which there are newer versions available. This should be available in a future Giraffe Canary (probably Canary 3). The existing Project Structure Dialog support for suggesting updates to dependencies should continue to work also. (In both cases this is limited to the declarative dependency declarations in toml files, not to declarations in code directly in settings.gradle.)

wi...@gmail.com <wi...@gmail.com> #8Jan 24, 2023 01:41PM

Seriously, it's not going to support the DSL? The bug filed is against the DSL... the DSL seems to be the recommended format in the Gradle docs... how is this considered an acceptable solution?

sm...@gmail.com <sm...@gmail.com> #9Jan 31, 2023 06:48PM

yes, it would be good to have support for gradle dsl, currently AS Electric Eel have a great support for toml and that's a good point,
also i would suggest that pressing ctrl + click on a dependency redirect to the dsl or toml file instead of redirecting to the generated code as it is the case actually,
like for view binding, when you ctrl + click on view binding it redirect to the xml file rather than the generated code

xa...@google.com <xa...@google.com> #10Mar 31, 2023 06:15PM

| the DSL seems to be the recommended format in the Gradle docs...

I just want to comment that it is actually not the recommended format. We've discussed this with Gradle, and their point is that the DSL is easier to use in the document to introduce concepts so they use it, but it does not imply that people should use the DSL over the toml format.

One clear benefit of the toml format is its support for tooling. Being a data file makes it a lot easier for tools to read/write it. This is why we are mostly going to support toml. We should probably warn users when they use the DSL that the support is incomplete.

gr...@zimmerbiomet.com <gr...@zimmerbiomet.com> #11Apr 3, 2023 03:16PM

Wonderful, you have found an example of where being technically correct is not better! :) The first five examples are the DSL. Why even bother to have it if the tools won't support it? If only there were a way to represent both with an intermediary internal format that could provide feedback on either!

xa...@google.com <xa...@google.com> #12Apr 3, 2023 03:41PM

The first five examples are the DSL. Why even bother to have it if the tools won't support it?

Because Gradle needs this from an API point of view so that Plugin can contribute to the catalog if needed, but there's no difference between the plugin API and the DSL, so it's expose as the DSL too.

I've given this feedback to Gradle in the past, and I will give it to them again (pointing to this issue).

gr...@zimmerbiomet.com <gr...@zimmerbiomet.com> #13Apr 4, 2023 05:27PM

Thank you!

hg...@hayhouse.com <hg...@hayhouse.com> #14May 15, 2023 01:09PM

I recently migrated a large project's Gradle setup to Kotlin DSL, so this bug is a painpoint for us. My understanding was that DSL is the recommended approach for build configuration/dependency management and therefore is now enabled by default on new projects too - Source - Android docs:

Starting with Android Studio Giraffe, new projects use the Kotlin DSL (build.gradle.kts) by default for build configuration.

Should I roll it all back or is DSL support planned for this bug, or it there a different approach that's recommended instead?

xo...@google.com <xo...@google.com> #15May 15, 2023 01:30PM

I know of no current plan to support Version Catalogs expressed directly in the settings Dsl, whether that is expressed in Groovy or Kotlin Script.

Version catalogs defined in separate, declarative .toml files should have all the usual lint inspections associated with them (minimal example in screenshot, not intended to display good practice); our suggested migration path to using Version Catalogs is [https://developer.android.com/build/migrate-to-catalogs]. I hope that helps, but if there's something I'm not understanding about your setup, please share as much detail as you can!

Screenshot from 2023-05-15 14-29-01.png

19 KB

View

Download

hg...@hayhouse.com <hg...@hayhouse.com> #16May 16, 2023 07:49PM

Thanks for the quick response. I didn't realize that the TOML could be used with the DSL for the version catalog, so I just converted my version catalog from the settings.gradle.kts to libs.versions.toml and everything is working great now. Thank you!

sm...@gmail.com <sm...@gmail.com> #17Jul 11, 2023 12:25PM

Hi, so version catalog will suggest new update in Android Studio Giraffe and also with lint in toml ?
before the update to AS Flamingo, the ide suggested update in the project structure dialog > Dependencies & Suggestions, now it suggest only update for a few libraries

sm...@gmail.com <sm...@gmail.com> #18Jul 11, 2023 12:57PM

Comment has been deleted.

Message last modified on Jul 11, 2023 01:07PM

jz...@gmail.com <jz...@gmail.com> #19Sep 21, 2023 06:37AM

I don't know if this is a bug, I used version catalogs and applied the toml file, then I published it to maven, and when I used groovy (build.gradle) to apply it, I can jump to the toml with ctrl+keypress file; and if I use kts (build.gradle.kts) to apply it, I find that I can only jump to the code generated by gradle, not the toml file. I expect to jump to the toml file. Thanks!

xo...@google.com <xo...@google.com> #20Sep 21, 2023 03:43PM

Reassigned to xo...@google.com.

regarding comment #19: I think that's expected behaviour in Giraffe; however, we have work-in-progress in Hedgehog and Iguana which should substantially improve navigation between toml and gradle build files (both Groovy and Kts). If you can reproduce your navigation issue in Iguana canaries, please file a new bug with instructions to reproduce so that we can address it.

sm...@gmail.com <sm...@gmail.com> #21Oct 12, 2023 12:49PM

comment #20

in AS Giraffe pressing ctrl + click now redirect to the toml file as suggested in

comment #9

using .kts gradle build file

Message last modified on Oct 12, 2023 12:50PM

xo...@google.com <xo...@google.com> #22Aug 27, 2024 01:41PM

Status: Won't Fix (Obsolete)

This issue has accumulated a number of different aspects / requests over the last few years.

It's basically infeasible to support smart editor tooling for programmatic declaration of dependencies in settings.gradle[.kts]: certainly with reasonable resources. Instead, we recommend declaring dependencies in gradle/libs.versions.toml, and using those names in the rest of the project.

Dependencies declared in gradle/libs.versions.toml should end up with all the IDE tools and affordances that literal dependencies in build files had: in-editor highlighting and quickfixes for outdated dependencies (under some slightly complicated conditions); upgrade suggestions in the Project Structure Dialog. Navigation to and from direct uses of version catalog entities should also work as expected.

Gradle's documentation style (using the DSL to explain new concepts, arguably misleading people about the best way to use a feature) is out of our control.

Based on all this, I think this issue's status is now somewhere between Obsolete and Infeasible: the things that can be implemented have been, and those that can't reasonably be, won't. For any new, specific issues working with version catalogs in Android Studio, please open a separate report. Thanks to all who contributed to the discussion and implementation.