Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a more Gradle-native syntax to specify Python dependencies in the Gradle plugin #461

Open
sschuberth opened this issue Dec 19, 2024 · 0 comments
Assignees

Comments

@sschuberth
Copy link

sschuberth commented Dec 19, 2024

Currently, specifying Python dependencies from Gradle seems to work like:

plugins {
    id("org.graalvm.python") version "24.1.1"
}

graalPy {
    packages = setOf("pyfiglet==1.0.2")
}

As a Gradle user, I'd expect a syntax that is more "native" to Gradle, e.g. via a graalPy Gradle configuration:

plugins {
    id("org.graalvm.python") version "24.1.1"
}

dependencies {
    graalPy("pyfiglet:1.0.2")
}

While I haven't tested this, I assume that as the configuration will be resolved by the plugin, the dependency notation can omit the usual group name. If for whatever reason a group name would be syntactically required, a dummy name like "python" could be added.

Background: I'm inspired by how the JRuby Gradle plugin does it (note that this is still Groovy instead of Kotlin DSL syntax):

dependencies {
    /* Using the built-in `jrubyJar` configuration to describe the
     * dependencies our jrubyJar task will need, so the gem is properly
     * included in the resulting .jar file
     */
    jrubyJar "rubygems:colorize:0.7.7+"
    jrubyJar 'org.slf4j:slf4j-simple:1.7.12'
}

Following this approach consistently across all Gradle plugins for GraalVM languages would make a great Gradle user experience IMO, and maybe all Gradle plugins could even share some common code (to create those language-specific configurations etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants