Populate a package's `scope` field
Closed this issue · 4 comments
While currently GitHub's dependency submission API only supports "runtime" and "development" scopes (which do not map really well to Gradle's configurations) it'd still be useful to have some coarse distinction here. Maybe compileOnly stuff should go to "development", and everything else to "runtime"?
It's particularly difficult to determine this, as it's very context-dependent. Take a look at the gradle/gradle build. There is quite a bit of logic in there that is just Gradle plugins that the Gradle team use to build/test Gradle itself. Are the dependencies used in those "development" or "runtime". What about test dependencies? Are those "development" or "runtime"? Test dependencies are used during a runtime, but is that the one we're concerned with?
Regarding your proposal to use compileOnly as "development", doesn't the API you compile against matter at runtime, as it can determine API compatibility? Is everything else truly "runtime"?
What about test dependencies? Are those "development" or "runtime"?
Yeah, I agree that "test" is definitely missing from the available choices. Maybe you guys could first work with GitHub to extend the list of supported scopes?
Is everything else truly "runtime"?
No. It was just a best-effort proposal to do something somewhat meaningful with the options at hand.
But given that the options (i.e. supported values for "scope") are so limited, it's maybe indeed better to not populate this field at all yet...
But given that the options (i.e. supported values for "scope") are so limited, it's maybe indeed better to not populate this field at all yet...
That was my thought, at least in the short term. If GitHub figures out a better explanation for what they want it to mean, we can maybe use it.
The other problem we have is that configurations can also be created custom by plugin authors. We don't really know what the use of those are.
Ok, let's then close this for now and eventually reopen once GitHub supports more scopes... maybe even just a free string without any general semantics attached (leaving it up to the user to interpret the meaning), so that we could literally tale the Gradle configuration name as-is.