supabase-community / supabase-kt

A Kotlin Multiplatform Client for Supabase.
https://supabase.com/docs/reference/kotlin/introduction
MIT License
379 stars 37 forks source link

[Question]: I think it's better to move the samples to root project? #573

Open MohamedRejeb opened 5 months ago

MohamedRejeb commented 5 months ago

General info

What is your question?

HI, I think it's better to move samples to the root project, it's easier for testing and debugging. You can directly run the sample with the latest changes without the need to publish the library. Also, when you clone the project, the IDE will only recognize the root project and you need to open the samples as separate projects.

Relevant log output (optional)

No response

jan-tennert commented 5 months ago

Yea, I think that should be fine. Originally there were some problems with Compose in the same class path, but that has been fixed a while ago.

jan-tennert commented 3 months ago

Handling this currently, unsure if this as easy as it sounds. Each sample has their own modules & settings, which makes it hard to include them all without a lot of boilerplate. Looking at the KotlinX dependencies, most of them have samples with their own gradle project.

jan-tennert commented 3 months ago

@MohamedRejeb any idea on this?

MohamedRejeb commented 3 months ago

I think that the library needs convention plugins, it will make this much easier. The build.gradle files will look like this https://github.com/MohamedRejeb/Calf/blob/main/calf-file-picker/build.gradle.kts

I can work on this if it makes sense to you. For modules with different targets we can have different function to setup targets depending on the case.

jan-tennert commented 3 months ago

If we mean the same thing, we already have some methods to make the configuration easier: https://github.com/supabase-community/supabase-kt/blob/master/Storage/build.gradle.kts But yea, we can probably continue improving on these, if we include all samples. I'm wondering, how should we handle the project build (when changes get merged into master)? We could try to build & compile all samples in the GH actions, but that is probably going to take ages since building the root project already takes 40 min. Same with the PR actions, but they currently only include tests not full project builds.

jan-tennert commented 3 months ago

root project already takes 40 min.

Probably a bit less if the Gradle files are cached, but its still ~25-30min.

MohamedRejeb commented 2 months ago

We can conditionally exclude samples from build when needed. Something like this should work:

if (System.getProperty("LibrariesOnly") != "true") {
    include(":sample:kmp")
}
./gradlew -PLibrariesOnly=true build