carthage / commandant Goto Github PK

OS: Linux, Ubuntu 16.04

Commands ran:

felix@felix-X550LD ~/D/P/A/commandant> rm -rf .build/
felix@felix-X550LD ~/D/P/A/commandant> git checkout 0.13.0 
Note: checking out '0.13.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 7f29606... Release 0.13.0
felix@felix-X550LD ~/D/P/A/commandant> swift test

Failed test output:

Test Case 'XCTestCase.OrderedSet, should preserve the order of the given input' started at 2018-04-09 22:11:17.477
/home/felix/Documents/Programming/AwesomeSystemSwift/commandant/Tests/CommandantTests/OrderedSetSpec.swift:17: error: XCTestCase.OrderedSet, should preserve the order of the given input : failed - expected to not equal <acb>, got <acb>

Test Case 'XCTestCase.OrderedSet, should preserve the order of the given input' failed (0.0 seconds)

What's the output on that line under Mac OS? Maybe it's failing on both ends.

Carthage/Carthage#1926

I think for the sake of better error messages Commandant should not try and convert flags to a set

It will mangle a --key typo and produce confusing errors.

If flags are passed as used ex:

$ carthage update -platform
Unrecognized arguments: -armpfolt

Should become

$ carthage update -platform
Unrecognized arguments: -platform

The --{no-}key syntax can be fairly limiting. We could support alternatives, like --with{out}-key, --{enable,disable}-key, etc.

jpsim/SourceKitten#174
Maybe that issue introduced since updating Commandant to the version that supports generating Unrecognized arguments error.

For fixing that, I tried:

    static func evaluate(m: CommandMode) -> Result<DocOptions, CommandantError<SourceKittenError>> {
        return create
            <*> m <| Option(key: "single-file", defaultValue: false, usage: "only document one file")
            <*> m <| Option(key: "module-name", defaultValue: "",    usage: "name of module to document (can't be used with `--single-file` or `--objc`)")
            <*> m <| Option(key: "objc",        defaultValue: false, usage: "document Objective-C headers")
            <*> m <| Argument(defaultValue: [], usage: "An argument list that consumes the rest of positional arguments")
    }

and got:

% cd Source/SourceKittenFrameworkTests/Fixtures
% sourcekitten doc --single-file Subscript.swift -j4 Subscript.swift
Unrecognized arguments: -j4

-j4 Subscript.swift are expected to use as arguments on launching child process.

Including combined syntax, like rm -rf (where r and f are two separate flags).

cibuild should, bootstrap should not.

Dependency injection is a really powerful pattern that makes unit testing much easier/possible.

It currently seems that Commandant is structured to encourage integration-style testing, which will never be as comprehensive (nor as fast) as unit testing. That is, it seems to be actively fighting my attempts to use DI for default arguments.

I bring this up because I'm trying to get the NSFileManager used in CheckoutCommand in Carthage be passed in instead of just new'd up (because it makes testing easier if I can just change out the currentDirectoryPath without having to muck with the file system).

However, I don't know what kind of API change to propose would be, hence issue, and not a pull request. Would like to get some kind of discussion on what it should look like, and even how it could be done (One idea I had was to use default arguments with the evaluate static method [so that it looks like static func evaluate(m: CommandMode, context: Any? = nil)], but swift doesn't allow default arguments in protocols).

Swift 5 adds the Result type to the standary library. It is no longer necessary to use a third-party dependency for Result. This dependency should be removed in favor the the native Result type.

Possibly out of date bootstrap script.

It appears that Commandant will not successfully build in the release configuration on Linux. This looks to be due to Quick being built and referencing the non-existent (in release) XCTest module. This does not happen on macOS, likely due to the conditional inclusion of Quick in Package.swift. I believe there are some workarounds for Test-only dependencies using SPM, but I am curious as to whether or not Quick is needed on Linux at all if it is not being included on macOS.

Steps to reproduce:

• Create a new trivial package (e.g. swift-package init --type executable)
• Add Commandant to Package.swift
• Build in release configuration using swift build -c release

Expected Results

Package builds without errors.

Actual Results

Package fails to build with linker errors related to Quick referencing XCTest.

#132 added support for CocoaPods by way of the Commandant.podspec file, which has been published. Myself and @ikesyo are the only owners of the pod right now.

Which other Carthage contributors would like to be granted ownership to help out with keeping CocoaPods updated with new releases of this library? Reply here and one of us will add you.

In realm/SwiftLint#1191, I'm adding an Argument. For an Argument initialized like this:

Argument(defaultValue: [""], usage: "list of paths to the files or directories to \(action)")

I get a help message that looks like this:

[[""]]
	list of paths to the files or directories to lint

It'd be nice if instead it looked more like this (to match arg interfaces in other cli tools):

[<paths…>]
	list of paths to the files or directories to lint

This may require the inclusion of a 3rd parameter to Argument called variableName.

Is it possible to create recursive commands like below ?

Carthage iOS update
Carthage iOS bootstrap
Carthage Mac bootstrap
Carthage Mac update

or are you considering this in future release ?

What I am really trying to do is that I have 2 command line applications suppose iOS and Mac and I am making a super command line application with my name rahulkatariya so that I can use the following commands

rahulkatariya ios <subcommand> <arguments>
rahulkatariya mac <subcommand> <arguments>

The version string of patch seems to be required in the current implementation of SPM. I executed swift package update with this manifest file and got the output as follow:

Cloning https://github.com/Carthage/Commandant.git
error: The dependency graph could not be satisfied. The package (https://github.com/Carthage/Commandant.git) with version tag in range (0.11.0..<0.11.9223372036854775807) is not found. Found tags ([0.1.1, 0.6.1, 0.7.0-beta.1, 0.7.0, 0.8.1, 0.8.2, 0.8.3, 0.9.0, 0.10.0, 0.10.1])

They are related source codes to this issue:

• https://github.com/apple/swift-package-manager/blob/swift-3.0-RELEASE/Sources/PackageDescription/Version+StringLiteralConvertible.swift#L40-L46
• https://github.com/apple/swift-package-manager/blob/swift-3.0-RELEASE/Sources/Utility/Git.swift#L78-L83

I'm trying to install Sourcery using SPM and Commandant has a dependency on Nimble 8.0.0 and my project has 9.0.0 so the mismatch isn't letting me install.

Imagine the following scenario:

Switch(flag: "f", key: "force", usage: "Whether to force")

Surprisingly, calling my-tool do something -f has a different than my-tool do something --force. The former one works, while the latter fails.

However, if the switch is initialized with: Switch(flag: nil, key: "force", usage: "Whether to force"), without a flag, --force works.

This is due to a (what I understand as a) bug in the Switch <| function:

case let .arguments(arguments):
    var enabled = arguments.consume(key: option.key)

    if let flag = option.flag {
        enabled = arguments.consumeBoolean(flag: flag)
    }
    return .success(enabled)

You can see that, when a flag exists, it will always read try to read if the flag was passed, and this will override the value if the key was passed.

I've opened a PR with tests and the fix for them.

I'm happy to do it, just wondering if there was a reason why it hadn't been done since last May. /cc @mdiep @ikesyo

Something like Carthage's main file would probably be generally useful.

Because Nimble is specified twice, with incompatible versions:

1. First in Package.swift as .Package(url: "https://github.com/Quick/Nimble", majorVersion: 5, minor: 0)
2. Again in norio-nomura/Quick's Package.swift as .Package(url: "https://github.com/ikesyo/Nimble", "5.0.0-alpha.30.gm.candidate")

$ swift build
Cloning https://github.com/Quick/Nimble
HEAD is now at 0209419 Move release notes file to tmp
Resolved version: 5.0.0
Cloning https://github.com/norio-nomura/Quick
HEAD is now at 8f2bc63 Use String over NSString
Resolved version: 0.10.0-alpha.30.gm.candidate
Cloning https://github.com/ikesyo/Nimble
/usr/bin/git clone --recursive --depth 10 https://github.com/ikesyo/Nimble /Commandant/Packages/Nimble
fatal: destination path '/Commandant/Packages/Nimble' already exists and is not an empty directory.

swift-build: error: Git 2.0 or higher is required. Please update git and retry

This can be solved by removing the Nimble entry in Commandant's Package.swift.

Once that's done, a new release will be required for it to be available to consumers on Linux.

This idea came up on mas-cli/mas#281 and I'm wondering if there is a simple way to create a 2nd command that is exactly like another without duplicating the 1st command. Has anyone come across this use case before?

Currently, unrecognized arguments are silently ignored.

I ran the following commands:

# Cloning, checking out and build command go perfectly
git clone https://github.com/Carthage/Commandant
cd Commandant/
git checkout 0.12.0
swift build 
# Test command fails
swift test

And I get the following errors:

Compile Swift Module 'CommandantTests' (3 sources)
/home/felix/Documents/SKD/TestingDependencies/Commandant/Tests/CommandantTests/ExtensionsSpec.swift:11:8: error: no such module 'Nimble'
import Nimble
       ^
/home/felix/Documents/SKD/TestingDependencies/Commandant/Tests/CommandantTests/ExtensionsSpec.swift:11:8: error: no such module 'Nimble'
import Nimble
       ^
/home/felix/Documents/SKD/TestingDependencies/Commandant/Tests/CommandantTests/ExtensionsSpec.swift:11:8: error: no such module 'Nimble'
import Nimble
       ^
<unknown>:0: error: build had 1 command failures
error: exit(1): /build/swift-FullSKLinux/usr/bin/swift-build-tool -f /home/felix/Documents/SKD/TestingDependencies/Commandant/.build/debug.yaml test

Seems like I'm missing Nimble as a dependency. How can I make it reachable by the testing command?

Since /usr/bin/which rejects -s argument.
Reproducing steps on Ubuntu with SwiftLint:

$ docker run -it --rm norionomura/swiftlint:swift-4.2 bash
root@5d3cc0804b2c:/# echo "echo swiftlint-test executed">/usr/bin/swiftlint-test
root@5d3cc0804b2c:/# chmod +x /usr/bin/swiftlint-test
root@5d3cc0804b2c:/# swiftlint test
Illegal option -s
Usage: /usr/bin/which [-a] args
Unrecognized command: 'test'. See `swiftlint help`.

The error below does not appear when running pod lib lint but it does appear while attempting to push a new spec version to trunk.

$ pod trunk push Commandant.podspec
...
[!] The Pod Specification did not pass validation.
The following validation failed:
- Warnings: Unrecognized `swift_version` key.

This is using CocoaPods 1.6.1.

% carthage checkout
*** Checking out SWXMLHash at "2.1.0"
*** Checking out Result at "1.0.2"
*** Checking out xcconfigs at "0.8.1"
*** Checking out Commandant at "0.8.3"
A shell task failed with exit code 1:
fatal: reference is not a tree: fcb11a2cbf08e10806039b8f767ab9072115d04d
Unable to checkout 'fcb11a2cbf08e10806039b8f767ab9072115d04d' in submodule path 'Carthage/Checkouts/Quick'

It seems Quick/Quick@fcb11a2 is not exists on tree of Quick that referenced by Commandant v0.8.3.

jpsim/SourceKitten#157

I want to create new Xcode project to build a CLI tool. So I open Xcode, I create a new command line tool project (using swift), then I try to add Commandant as a dependency, but, I cannot add frameworks as a dependency.

All the projects using Commandant have very peculiar xcodeproj. They seem standard OSX apps, but they are using build phases like "Extract CLI Tool".

Am I missing a tool or a bootstrap project?

Extract the help command from Carthage, to serve as a default for any user of Commandant.

Unrecognized command: '--help'. See carthage help. is not as helpful as it could be when parsing commands

if the argument that failed to parse contains help but was not exactly "executable help" the error should be printed and executable help should be run.

Maybe even -h