As a non-OSX user, I can't tell you. I'll look into it tomorrow.
On Mon, Jan 3, 2022, 6:24 PM Reuven Lax <re...@google.com> wrote: > Also xcun is installed on my machine, just not under > Library/Developer/CommandLineTools/. Is there something about the new go > version that's causing it to look in that directory? > > On Mon, Jan 3, 2022 at 6:19 PM Reuven Lax <re...@google.com> wrote: > >> I was running spotlessApply - which is pretty much a prerequisite for >> submitting any code to Beam. >> >> On Mon, Jan 3, 2022 at 6:16 PM Robert Burke <rob...@frantil.com> wrote: >> >>> Xcrun is news to me. Something in the go toolchain for that command I >>> guess. I assume you might not have xcode tools installed. Eg. >>> https://developer.apple.com/forums/thread/673827 >>> >>> Were you running the :sdks:go:test target directly? >>> >>> On Mon, Jan 3, 2022, 6:11 PM Reuven Lax <re...@google.com> wrote: >>> >>>> I am trying to run ./gradlew spotlessApply, and I'm getting go errors. >>>> I've updated the go version, but I'm still getting the following error. Any >>>> idea what I'm doing wrong? >>>> >>>> *> Configure project :sdks:go:test* >>>> >>>> System Go installation: /usr/local/go/bin/go is go version go1.16.12 >>>> darwin/amd64; Preparing to use /Users/relax/go/bin/go1.16.12 >>>> >>>> # runtime/cgo >>>> >>>> xcrun: error: invalid active developer path >>>> (/Library/Developer/CommandLineTools), missing xcrun at: >>>> /Library/Developer/CommandLineTools/usr/bin/xcrun >>>> >>>> >>>> FAILURE: Build failed with an exception. >>>> >>>> >>>> * Where: >>>> >>>> Build file '/Users/relax/beam/sdks/go/test/build.gradle' line: 20 >>>> >>>> >>>> * What went wrong: >>>> >>>> A problem occurred evaluating project ':sdks:go:test'. >>>> >>>> > Could not create task ':sdks:go:test:goPrepare'. >>>> >>>> > Process 'command 'sh'' finished with non-zero exit value 2 >>>> >>>> On Thu, Dec 30, 2021 at 10:10 AM Robert Burke <rob...@frantil.com> >>>> wrote: >>>> >>>>> Great graphs Luke! >>>>> >>>>> Related note: with this migration the project no longer uses the >>>>> GoGradle plugin to build or test any Go source. They have been replaced >>>>> with shell script that bootstrap to a set version of go. This is tracked >>>>> in BEAM-12830 [1]. >>>>> >>>>> This touches all portable builds as the project uses small Go programs >>>>> for portable container bootstrap. >>>>> >>>>> The following are the consequences of this change and known issues: >>>>> >>>>> * The project requires a minimum of Go 1.16 to bootstrap to arbitrary >>>>> Go versions going forward. >>>>> * Presently Nightly Snapshots are broken since the shared infra >>>>> machine is on Go 1.10. Beam tracking for this issue is at BEAM-13540 [2]. >>>>> See that for the paired ticket to Infra for upgrading. >>>>> >>>>> * OSX users can't currently run the Go integration tests locally, due >>>>> to the scripts not currently building both the local host platform version >>>>> and the container required version of pipelines. >>>>> * This is a small inconvenience as it only prevents using the gradle >>>>> scripts, and not using beam by using Go directly. >>>>> >>>>> If there are any other issues related to the removal of GoGradle, or >>>>> either of these limitations become urgent, please let me know so a fix can >>>>> be expedited. >>>>> >>>>> Cheers, >>>>> Robert Burke >>>>> Beam Go Busybody >>>>> >>>>> 1: https://issues.apache.org/jira/browse/BEAM-12830 >>>>> >>>>> 2: https://issues.apache.org/jira/browse/BEAM-13540 >>>>> >>>>> >>>>> >>>>> On Thu, Dec 30, 2021, 9:45 AM Luke Cwik <lc...@google.com> wrote: >>>>> >>>>>> The migration to gradle 7[1] happened in the past two weeks. As part >>>>>> of that migration many plugins had to be updated or replaced if a newer >>>>>> gradle 7 compatible version couldn't be found and dependencies were moved >>>>>> away from the removed configurations such as "compile" and "testCompile" >>>>>> (more on this below). If you experience issues during your development >>>>>> process that you suspect is due to the migration, feel free to reach out. >>>>>> >>>>>> For the removed configurations (boxes with light gray text), the >>>>>> gradle migration guide[2] suggested that existing usages of "compile" be >>>>>> replaced with "implementation" and "testCompile" with >>>>>> "testImplementation". >>>>>> Usages of "runtime" and "testRuntime" are more complicated since Gradle 7 >>>>>> forced the split of configurations used to declare dependencies (light >>>>>> green) and configurations that are consumed by tasks (blue gray). A new >>>>>> configuration called "testRuntimeMigration" was created for the purpose >>>>>> of >>>>>> migrating the widely used "testRuntime" configuration. The >>>>>> "testRuntimeConfiguration" contains the current modules test jar and >>>>>> extends the "testRuntimeOnly" and "testImplementation" configurations >>>>>> effectively creating something similar to the "testRuntimeClasspath" >>>>>> which >>>>>> can be consumed by tasks and used to declare dependencies to other >>>>>> modules >>>>>> tests. This seems to be working at the moment but open to suggestions on >>>>>> how to re-organize this cleanly (e.g. should jar also add to >>>>>> "testRuntimeMigration"). >>>>>> >>>>>> For the main source set: >>>>>> [image: image.png] >>>>>> >>>>>> For the test source set (forgive my paint skills): >>>>>> [image: image.png] >>>>>> >>>>>> >>>>>> 1: https://issues.apache.org/jira/browse/BEAM-13430 >>>>>> 2: >>>>>> https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal >>>>>> >>>>>
