gfontenot / vim-xcode Goto Github PK

Now that vim has first class async support, it would be awesome for this to be integrated into vim-xcode

Because we don't have anything setting -o pipefail, if xcodebuild fails, xcpretty will still succeed, which isn't awesome. I don't know if this will be a huge issue, but it's probably worth noting.

While editing a test it would be great to be able to run it and only it. Or to specify a test class or file to quickly test.

This will be tricky. If you look at facebooks xctool you will find they do this by creating a temporary scheme.

We're hard coding a lot of iOS stuff in here right now, specifically with testing. We should be better about making that part dynamic and let people test OS X apps and frameworks.

This is also going to be important with watchOS/tvOS.

I think there's also a thing that should work nicely with tmux, but in reality, this is just a glorified xcodebuild flag generator. So if we just make the command to be run more dynamic (like in rspec.vim), we should be able to support all kinds of neat setups.

Thesis

• vim-xcode is currently able to build a complete command to build or test an Xcode project
• vim-test is able to look at files and pick test runners based on those files in order to run a suite of tests, a single file's tests, or even a single test.
• xcodebuild now (I don't know when this was added) has the ability to run individual test bundles/classes/cases with a flag: -only-testing:Bundle[/Class[/Case]].

We should be able to hook these up nicely.

Implementation

Building the command building logic into vim-test itself probably doesn't make sense since there's plenty of intricacy involved and we'd end up re-implementing the bulk of vim-xcode. Likewise, vim-test has a lot of logic for parsing the bundle/class/case from a single file and building a flag (or list of flags) to pass to a test runner command accordingly that doesn't really make sense to duplicate here. That being said, we should be able expose the plumbing needed in vim-xcode and then end-users can add some local config in order to expose it to vim-test.

The gist would be to ship a test new runner integration with vim-xcode. This basically just means adding an autoload/test/xcode/xcode.vim file to this plugin and following the extension steps laid out by vim-test. End-users would then need to add let test#custom_runners = {'Xcode': ['Xcode']} to their local vimrc in order for vim-test to see our runner. We'd also need to open up some of the internals of vim-xcode via exposed functions (xcode#test_command(), for example) so that we can access them from the vim-test integration.

Problems

Some issues I've run into this while testing that would need to be figured out (this list might change over time):

• How do we disambiguate between testing with Xcode and testing with swift test when they are both technically valid options? We might need to add something similar to the explicit runner selection config they have for Python and Go, but I'm not entirely sure how that would/should work since the only "official" runner is swiftpm.
• How do we determine the test bundle properly? If the bundle doesn't match the name of the directory on disk, the command will end up erroring. For example, parsing the test bundle for Argo based on the file structure would result in ArgoTests. This is fine if you're testing the Argo-iOS scheme because that happens to be the name of the test bundle in Xcode. But if you test the Argo-Mac scheme, it fails with a semi cryptic error because there are no available tests. To make things worse, while you can run xcodebuild -list to get a list of possible targets, there's really no way to 100% tell which target is a test target, and no way at all to tell which targets are linked to which schemes.

When using Cocoapods you have a workspace where all the schemes of the pods and your own schemes exist.
Most of the time you don't want to run the pods schemes but only your own.

I would like to have an option to ignore the workspace for the list of your schemes.

If you don't like this option another way to fix this would be to look for Pods.xcodeproj and substract these schemes.

I'd try to implement this myself, if you'd be open to merge it 👍

If we can pass a file to XOpen, it would mean we could do things like XOpen % to open the current file in a new Xcode window, which would be useful. It would also mean we could do XOpen path/to/my/cool/Storyboard.storyboard and get a new window with just that storyboard in it.

Right now, we have to get the scheme every time we do anything and it turns out, xcodebuild -list is super slow. It'd be rad to cache this somewhere on disk so that we can get a kind of memoization thing going on.

We don't have any tests right now, although it'd probably be nice to have some. At the very least we could have shellcheck run against the bin directory to avoid issues like those in #55.

Right now we're just showing the raw output, it might be nice to use a status window or some other neat trick so that vim doesn't lose focus. I have no idea how this would work.

ffs how is this so awful?

xcodebuild doesn't find implicit dependencies the same way Xcode finds implicit dependencies so it's super unreliable. This really fucking sucks, and means that users would either have to avoid implicit dependencies (ugh) or... I have no idea. I don't know how else to fix this.

I haven't been able to successfully run in the simulator yet. Here's the output I'm seeing:

find: ftsopen: No such file or directory
2016-07-12 17:58:49.918 defaults[19684:4476942] 
The domain/default pair of (/Info, CFBundleIdentifier) does not exist

I'm going to dig around in the code to see if I can work out what's going wrong.

We aren't escaping enough.

the -sdk flag apparently isn't super useful. We should switch to using -destination

Specifically:

• when building an iOS app: -destination 'generic/platform=iOS'
• when testing an iOS app: -destination 'platform=iPhone Simulator,device=iPhone 6'
• when building or testing a mac app: -destination 'platform=OS X' (haven't tested this)

I have an Xcode project, cd there. Then open it with vim . because I want to try out this swell tool.

Anyway :Xbuild fails on first try.

Error detected while processing function <SNR>33_build..<SNR>33_assert_project..<SNR>33_project_files:
line    1:
E118: Too many arguments for function: globpath
E15: Invalid expression: globpath(expand('.'), '*.xcodeproj', 0, 1)
Error detected while processing function <SNR>33_build..<SNR>33_assert_project..<SNR>33_workspace_files:
line    1:
E118: Too many arguments for function: globpath
E15: Invalid expression: globpath(expand('.'), '*.xcworkspace', 0, 1)
No Xcode project file found!

My guess is that this is because of spaces in the name of my project file. Not sure where to start debugging beyond just my guess.

Project name is "WM To Go.xcodeproj" (Also no there is no .xcworkspace, cocoapods is configured on the other branch)

With #23, we're letting users explicitly set the scheme to test or build. That's fantastic, but it would be really great to add some autocompletion to improve the user experience.

This would probably entail changing the scheme finding script to return a list of schemes instead of a single scheme, and then caching that list.

Right now we're exposing commands like XOpen and XBuild and XTest. However, fugitive exposes commands like Gw and Gbrowse. It seems like we should lowercase the second letter in our command names to follow suit.

Right now we just pick up the first available scheme, which isn't ideal. It'd be better if we could somehow let users choose which scheme to build.

Instead of autocompleting the simulator selection (see #8) to any simulator, it'd be nice to limit the selection to simulators supported by the specified scheme.

CORRESPONDING_SIMULATOR_PLATFORM_NAME and SUPPORTED_PLATFORMS hold some info about what simulators are supported by the selected scheme, that might be helpful?

I know this plugin does a great job as a wrapper over xcodebuild. But do we have any approach on peaking at the runtime log while the app is running in the simulator?

Right now, if I select a scheme, that selection is reset the next time I open the project. That kinda sucks. It might be better for user specified things like that to be cached in some way that we can check for when starting up.

Probably also means we should introduce some way to clear/reset the cache.

We're defaulting to --color --test, but that's pretty prescriptive. I think it'd be better to default to no flags (or maybe just --color) and let users customize the flags passed to xcpretty via a configuration option.

I'm not sure if there's a way to limit the -complete=file autocompletion to files matching a pattern but it seems like it'd be really nice to be able to only show files that end in .xcodeproj.

When executing :Xbuild or :Xrun the output shows "Run Script" twice.

Press ENTER or type command to continue
▸ Building WM To Go/WM To Go [Debug]
▸ Check Dependencies
▸ Running script 'Run Script'
▸ Running script 'Run Script'
▸ Build Succeeded
com.walmart.delivery: 9573

Press ENTER or type command to continue

Not sure why this is, but I wanted to report it and help debug if needed.

Thanks.

For iOS projects, this should use the XBuild command to build the project, then use simctl (xcrun simctl) to install the app.

# build
xcrun simctl install booted <path to built app>
xcrun simctl launch booted <app identifier> # this might be problematic

simctl usage:

Usage: simctl [--noxpc] [--set <set path>] <subcommand> ... | help [subcommand]
Command line utility to control the Simulator

For subcommands that require a <device> argument, you may specify a device UDID
or the special "booted" string which will cause simctl to pick a booted device.
If multiple devices are booted when the "booted" device is selected, simctl
will choose one of them.

Subcommands:
        create              Create a new device.
        delete              Delete a device or all unavailable devices.
        pair                Create a new watch / phone pair.
        unpair              Unpair a watch and phone phone.
        erase               Erase a device's contents and settings.
        boot                Boot a device.
        shutdown            Shutdown a device.
        rename              Rename a device.
        getenv              Print an environment variable from a running device.
        openurl             Open a URL in a device.
        addphoto            Add photos to the photo library of a device.
        install             Install an app on a device.
        uninstall           Uninstall an app from a device.
        get_app_container   Print the path of the intsalled app's container
        launch              Launch an application by identifier on a device.
        spawn               Spawn a process on a device.
        list                List available devices, device types, runtimes, or device pairs.
        icloud_sync         Trigger iCloud sync on a device.
        help                Prints the usage for a given subcommand.

I should be able to use AsyncRun as my runner right? (yay vim8.0!) I tried replacing the runner variable, but that made vim freeze up. Is there anything that would prevent this from happening you think?

I'm getting further since #60 was fixed, but not quite all the way there yet. The application appears to successfully install in the simulator, but then fails to open:

An error was encountered processing the command (domain=FBSOpenApplicationErrorDomain, code=1):
The operation couldn’t be completed. (FBSOpenApplicationErrorDomain error 1.)

This could be related: http://stackoverflow.com/questions/31350957/fbsopenapplicationerrordomain-error-1. Something to do with environment variables on launch. I'll try take a look into this later.

This is starting to be a little more than a wrapper around xcodebuild, and I think we're going to get further away from that. It seems like this plugin wants to be a way to work with Xcode projects themselves from within vim. For example, I'd really like to add a function for adding files to the Xcode index. That's way outside the scope of xcodebuild.

I succeeded install xcode.vim via Vundle in my first time. But for subsequent attempts, it pops out this error:

Error detected while processing ~/.vim/bundle/vim-xcode/plugin/xcode.vim:
line   55:
E122: Function <SNR>87_run already exists, add ! to replace it

However, I'm still able to use the plugin normally. It's just an annoying alert whenever vundle executed. Does anybody have this issue?

ideally, users would be able to (at least) pick an OS version to run against. This seems fairly important. We could (should) probably go further, and let users decide which simulator to run against.

We aren't doing this correctly everywhere right now.

Very possibly out of scope for this project, but one of the main advantages of working in Xcode is code completion. SourceKittenDaemon seems to provide the main pieces for getting this to work from inside of vim, which would make Xcode.vim an extremely compelling alternative to Xcode itself.

https://github.com/terhechte/SourceKittenDaemon

Idea/pitch

So I'm not sure how difficult this might be, but what do you think about adding support for customizing test command arguments?

The two main use-cases I thought of are below.

Parallel testing with Xcode 10

set via g:xcodetest_arguments
https://medium.com/xcblog/wwdc18-xcode-10-in-action-f56e14c62d79

$ xcodebuild -project Xcode10-Demo.xcodeproj/ -scheme Xcode10-Demo -destination 'platform=iOS Simulator,OS=12.0,name=iPhone X' clean build test CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO -parallel-testing-worker-count 4

Running specific tests/test suites

https://stackoverflow.com/questions/35166214/running-individual-xctest-ui-unit-test-cases-for-ios-apps-from-the-command-li
set via g:xcodetest_arguments or : Xtest -only-testing:TestBundle/TestSuite/TestCase

xcodebuild test -workspace <path> -scheme <name> -destination <specifier> -only-testing:TestBundle/TestSuite/TestCase

Unfortunately, we're currently requiring users to build the app then run it as two different steps. This kinda sucks, and it'd be better if we could have some kind of build and run option.

Since we don't actually know when the build command finishes, it's probably best to generate the build command and the run command then send them both to the runner as build && run.

if you have tmux misconfigured, xcrun instruments isn't able to communicate with the simulator (?) properly. We should probably add a note in the async build section of the README and in the Xrun section of the documentation about this.

/cc @sharplet

Right now, if there are multiple projects in the root directory, basically everything breaks. This is because we send all of the projects to the various commands that expect a project file instead of choosing just one.

Obviously, this isn't ideal. It'd be nice to figure out a nice way to select these from disk. Maybe default to the first, but let users specify one via a command (like we do with XSelectScheme?)

xcodebuild likes to spew lots of error messages about plugins. For example:

2015-09-10 16:33:24.329 xcodebuild[9442:73661] [MT] PluginLoading: Required plug-in compatibility UUID 0420B86A-AA43-4792-9ED0-6FE0F2B16A13 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/XcodeColors.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2015-09-10 16:33:24.330 xcodebuild[9442:73661] [MT] PluginLoading: Required plug-in compatibility UUID 0420B86A-AA43-4792-9ED0-6FE0F2B16A13 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/FuzzyAutocomplete.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2015-09-10 16:33:24.330 xcodebuild[9442:73661] Failed to load plugin at: /Users/ksmiley/Library/Application Support/Developer/Shared/Xcode/Plug-ins/FuzzyAutocomplete.xcplugin, skipping.  Reason for failure: *** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]

It would probably be nice to silence this when using xcodebuild to load things like schemes by redirecting the output with something like: xcodebuild -list -project foo.xcodeproj 2>/dev/null