Problem when creating `default` configuration

[s1ck]

trafficstars

Hey, I am trying to configure the plugin in an existing Gradle project. Your example project runs just fine. However, when I add the plugin to the existing project, I get:

An exception occurred applying plugin request [id: 'fr.stardustenterprises.rust.wrapper']
> Failed to apply plugin 'fr.stardustenterprises.rust.wrapper'.
   > Cannot add a configuration with name 'default' as a configuration with that name already exists.

Which is caused by: https://github.com/stardust-enterprises/gradle-rust/blob/91c333fc33deb0ce0d011e0e2f02181aa444517f/src/main/kotlin/fr/stardustenterprises/gradle/rust/wrapper/WrapperPlugin.kt#L24

If a default configuration already exists (which is the case here), it throws.

I am not sure if creating a configuration is strictly necessary, but if so, we could change the call to .maybeCreate which has create-if-not-exists semantics. wdyt?

[s1ck]

I could verify locally that this solves the problem, but it continues with:

> Failed to apply plugin 'fr.stardustenterprises.rust.wrapper'.
   > Cannot add task 'build' as a task with that name already exists.

I can successfully integrate it my project if I rename the tasks, i.e.

@Task(group = "rust", name = "buildRust")
@Task(group = "rust", name = "testRust")
@Task(group = "rust", name = "runRust")
@Task(group = "rust", name = "cleanRust")

What do you think? Should I open a PR for that change?

[edit] Seems to be somewhat the default, e.g. for the python gradle plugin:

Python tasks
------------
checkPython - Validate python environment
cleanPython - Removes existing python environment (virtualenv)
pipInstall - Install pip modules
pipList - Show all installed modules
pipUpdates - Check if new versions available for declared pip modules

[xtrm-en]

Hey, thanks for the feedback!
gradle-rust works in a very odd manner right now: it bundles two Gradle plugins:

• the wrapper plugin (fr.stardustenterprises.rust.wrapper)
• the importer plugin (fr.stardustenterprises.rust.importer)

The wrapper plugin was originally intended to be used in a rust-only module, to be then imported via the importer plugin in a second Gradle subproject.

This behavior isn't ideal but was the one I deemed sufficient enough with my at-the-time limited knowledge of proper Gradle ways, to work in all cases, albeit with a bit of refactoring.

As per your proposals:

• maybeCreate for the configuration is definitely a good idea, you can PR that in right away if you'd like and I'll publish it in a day or so
• pre/suffixing tasks names that clash with default Gradle ones is a bit trickier, since those need to work for every other plugin that hook into them, and in the right order for dependencies (maybe Gradle handles this automagically?). If you want and open a PR for that too that'll be lovely of course.

I'll try and look into how I can improve the developer experience with gradle-rust based on that second point (i.e. not splitting the project in two plugins), but do note that it'll probably take a bit of time as I'm taking a break from programming to handle changes and life in general :+1:

You can also try and separate your module layout to work in the current gradle-rust fashion if that's possible for your workflow; there isn't much in terms of proper documentation, only this example project which should serve as a bare-bones template.

[xtrm-en]

Addendum: I'm currently rewriting this Gradle plugin from the ground up, with new knowledge about Gradle.

First things off, it will be bundled as a singular gradle plugin, this division made things way too confusing.

It will try to follow what official Gradle language plugins (think groovy or scala) are doing, with source set integration, whilst still supporting wrapping a simple Cargo build.

Also, to make more sense of my past self:

[...] since those need to work for every other plugin that hook into them [...] maybe Gradle handles this automagically?

I was talking about the LifecycleBasePlugin, which creates the build, assemble, check, and clean tasks (see here). I didn't understand that at the time and manually registered those, making the build incompatible with any plugin applying either LifecycleBasePlugin or simply the BasePlugin plugin.

Hope this makes a bit more sense! I will keep this open as to not lose sight of this when developing v4, and will close it when I'm sure everything works correctly:tm: