<@U6158UG1Z> In my understanding Jetpack Compose i...

# compose

[Klaas Kabini]

@jim In my understanding Jetpack Compose is designed to allow extension to other platforms such as Desktop(Compose Desktop by JetBrains) and iOS. Therefore, are there any plans to change the package name in future to be platform agnostic for example something like com.google.compose instead of androidx.compose. The androidx.compose package gives an impression that Compose is Android specific.

[Alex]

AFAIR Compose is a system for managing a tree of nodes. Jetpack compose is the android specific implementation for rendering android UIs. Compose for Desktop is the desktop specific implementation. But compose in general doesn't have to be used for UI. I remember there being a very interesting article by Jake Wharton about this.
So it does not make sense to change the package, as jetpack compose will always be android specific. The iOS implementation would get its own package.

[Alex]

Here it is: https://jakewharton.com/a-jetpack-compose-by-any-other-name/

[Filip Wiesner]

😄 And that's why it does not only need package change but also name change. I think both of you are talking about the same thing but call it differently. Compose is both the tree management tool and the UI toolkit. That's why it's confusing.

[Klaas Kabini]

@Alex my argument still stands. The runtime used to manage the trees is still using the androidx namespace. Why is it tied to androidx namespace meanwhile it is mean’t to be general purpose?

[Klaas Kabini]

@Alex I have been experimenting with Compose since dev02 and I understand clearly how the runtime works in managing the trees. Even on Compose Desktop, JetBrains team has to import the runtime specific stuff on Compose Desktop which have android namespace. The runtime and the compiler were supposed to have a platform agnostic package.

[Colton Idle]

This has been discussed a few times in this slack. On mobile now, but use the search tool and you will find some lengthy conversations about it.

[Klaas Kabini]

Thanks @Colton Idle i would check those conversations. Last conversation I saw was a change.org petition for package name change by @louiscad. There is nothing much that happened after that.

[Klaas Kabini]

This is the last conversation I know about regarding this matter. https://kotlinlang.slack.com/archives/CJLTWPH7S/p1613212443389800

[Klaas Kabini]

🤣🤣🤣 I agree with @jw. https://jakewharton.com/a-jetpack-compose-by-any-other-name/

[Adam Powell]

We have read all of the appeals and objections around this as they've been raised and have no intention to change it. 🙂

[louiscad]

Random new name idea that will definitely convince Adam: rename Compose to Fragments2 blob delighted

[jw]

jfc no

[louiscad]

I wonder if the entire team sides with that "We" Adam is talking about… 🤔

[jim]

Probably not everyone agrees with the names, but I think everyone on the team agrees it is a little too late to change it now.

[louiscad]

Was it too late when I raised awareness of this naming thing, which was about a week before the first beta release?

[Colton Idle]

@louiscad patiently waiting for your podcast so you can invite jim onboard to ask him about naming. 🍳

🤣

[Colton Idle]

Jimposable ™️

[jim]

It wouldn't be interesting, I'd just toe the party line.

[louiscad]

Another thing I can do is make a Gradle plugin that renames Compose sources automatically for another package, then I set up a repo with GitHub Actions that automatically clone the latest releasable, apply the Gradle plugin, publish it to MavenCentral, so I keep up with Compose releases.

Then I start advertising it.

Then I make a bot that will do the same for other libraries, starting with Accompanist, and finally, apply the Gradle plugin to app projects.

[jw]

Sounds like a really terrible idea that accomplishes nothing.

[louiscad]

It would address the naming issue for sure, and that could make Compose UI be named "Crane" like you want.

The effort required for that, the used resources, and the incompatibility issues it could being certainly make it not worth it though.

[jw]

The name issue problem exists solely in Google's canonical artifacts and renaming them locally or in a parallel ecosystem only serves to make things worse. The package names / library names are almost entirely irrelevant when I'm programming with Compose locally. The canonical names that we (and most importantly Google itself) use are where the lack of specificity is a problem.