Drop support for SPM plug-ins

[calvincestari]

--disable-sandbox should be the preferred command line option in the docs because it enables the network requests needed for fetch-schema.

Currently the SwiftPM plug-in environment is a nice-to-have but suffers from some limitations, such as the Xcode experience and needing --disable-sandbox for extended functionality. We're making a decision to drop support for SwiftPM plug-ins and bring them back once the environment is more mature to fully support the experience we want to deliver.

[shumin0809]

+1 on this, would be good if we can disable it with the plugin option. Got same error on this thread

[calvincestari]

As far as I can tell from documentation and experience there is no way to disable this or pass in the option automatically; it has to be a user decision for security reasons.

Executing the command outside of the plug-in though it's not required.

[AnthonyMDev]

Yeah, this is an Apple security "feature"... We're exploring options for distributing the CLI outside of SPM plugins in the future.

[shumin0809]

thanks for replying. How can we disable the sandbox option with SPM plugins then? I looked up my project settings they all disable already. But still getting this error.

[DanielKrofchick]

@AnthonyMDev I'm running the Swift Package Manager - Xcode option and am getting the A server with the specified hostname could not be found. error when running ApolloCodegenPlugin-Fetch. I understand we need to disable the sandbox using --disable-sandbox, but there doesn't appear to be a way to do so using this method of running the Apollo CLI. Is there a solution for this? It would be good to have a clear answer, one way or the other. Thanks.

[AnthonyMDev]

When you open the prompt to run the plug-in, there is a drop down for “Arguments” where you can add the argument.

We will add this to the docs soon. This whole process is not ideal, and we are looking into how to best provide the CLI without SPM plugins in a user friendly way. It’s imperative that you are using the version of the CLI tied to the version of the library you are using and plugins made that part easy, but are causing a bunch of other usability issues such as this.

[DanielKrofchick]

I was hoping that would work, but unfortunately it appears that command is passed to the CLI instead. Perhaps I'm doing something wrong?

[shumin0809]

I was hoping that would work, but unfortunately it appears that command is passed to the CLI instead. Perhaps I'm doing something wrong?

I got the same error as well. Doesn't look like plugin-fetch works as expected.

[AnthonyMDev]

That is so frustrating. We'll look into if there is a way around this. But for now, you can build the CLI manually and run it. See the "Manual Installation" expandable section of this docs page.

[DanielKrofchick]

Will look at doing it manually. Thank you for the feedback @AnthonyMDev.

[shumin0809]

thanks @AnthonyMDev , cli works fine w/o disable sandbox option. Will have the team to leverage command line option instead of plugin for now.

[potrebic]

I've gotten --disable-sandbox to work (Thanks to this discussion!) when running via command line.

Also tricky/subtle is apparently the --allow-writing-to-package-directory option needs to go right before the plugin-command. So disabled-sandbox and other swift package options need to go first:

swift package --disable-sandbox \
   --package-path <DerivcedDataPath>/SourcePackages/checkouts/apollo-ios/  \
   --allow-writing-to-package-directory apollo-generate --path <path to apollo-codegen-config.json>

[calvincestari]

thanks @AnthonyMDev , cli works fine w/o disable sandbox option. Will have the team to leverage command line option instead of plugin for now.

@shumin0809 I believe that --disable-sandbox will be needed even for the CLI when fetching a schema which does network requests.

[AnthonyMDev]

@calvincestari I believe they were saying when used via manual installation. --disable-sandbox is only needed for the SPM plugin.

[SilverTab]

I seem to be stuck in the same situation; Initializing the config and generating the code works from within Xcode, but fetching the schema doesn't. Passing in --disable-sandbox via Xcode only passes that to the apollo-generate command, which doesn't know what to do with it, when really it should be passed to the swift package command. Haven't been able to find a work around, so for now I'm fetching the schema using the CLI that I manually installed, and generating the code via Xcode 😭

[calvincestari]

@calvincestari I believe they were saying when used via manual installation. --disable-sandbox is only needed for the SPM plugin.

Ah yes. Got it!

@SilverTab I'm not sure how to enable that option within Xcode just yet, or if it's even possible. Will keep digging.

[AnthonyMDev]

@SilverTab You're doing the right thing right now and have summarized the problem as it stands very well. :)

From within Xcode, there is no way to pass the --disable-sandbox argument to the plugin, which prevents network requests, thereby preventing schema fetching from working.

As I don't think there is a workaround for this, we are likely just going drop the Fetch command from the Xcode Plugin options and update the documentation to recommend that you manually install the CLI and use that.

I'm actually just considering if we should drop the Xcode Plugin completely. It doesn't seem to be any easier than just running the CLI manually, and I think it is confusing to be able to use it for some commands but not others... but I'd be interested in user feedback on that!

[Rheaparks]

Hello @AnthonyMDev, in my humble opinion, consistency is probably more important. Adopting 1.0 is certainly not straightforward as it currently stands. Jumping hoops for Xcode Plugin to work ain't no fun, particularly when it fails silently, even displaying a green checkmark upon erroring. I understand this is more of an Xcode problem, so dropping its support seems reasonable.

[SilverTab]

@AnthonyMDev The main reason I was interested in doing it via Xcode is really just to ensure that my CLI version is tied to the Apollo package version, so that if codegen changes for one reason or another, whenever I chose to update the Apollo package, my CLI is going to be in sync. I definitely wouldn't mind running the CLI in a terminal instead of in Xcode, but I would still be interested in a clear, documented way for people using Xcode to make sure that they can keep the Apollo package in sync with the CLI version!

[AnthonyMDev]

This is the exact reason why we haven't fully solved this issue yet. We're going to do our best to come up with a way to ensure the correct version of the CLI is always installed. I've got some ideas on that, but we need to actually do some proof of concept work to decide how to handle this!