Conversation
Package.swift
Outdated
| @@ -22,7 +22,7 @@ let package = Package( | |||
| // Targets are the basic building blocks of a package. A target can define a module or a test suite. | |||
| // Targets can depend on other targets in this package, and on products in packages which this package depends on. | |||
| .target( | |||
| name: "Mint", | |||
| name: "mint", | |||
There was a problem hiding this comment.
Instead of changing the target name to lowercase, I'd rather specify an explicit product with a lowercase name
.executable(name: "mint", targets: ["Mint"]),
There was a problem hiding this comment.
@yonaskolb, I will double check, but I am pretty sure that the name argument for products is only used in the manifests of other packages where they specify which of your products to actually use. I think it is the target name that defines the name of the executable file itself, and hence what you use from the shell.
If that is correct, then it would be reasonable to make the executable name uppercase if you want (for referencing in manifests), but the target name needs to lowercase unless you want the command to always be used capitalized, i.e. $ Mint install ..., which would be a little unusual.
There was a problem hiding this comment.
Just tested it. My assumption was wrong. Holdover from Swift 3 I guess.
There was a problem hiding this comment.
I will fix it.
There was a problem hiding this comment.
Can you rename the mint folder back to Mint as well then
There was a problem hiding this comment.
Actually, it only sort of works. The executable file gets the product name, but when the executable file differs from the corresponding target name (which I imagine is rare) some of swift package’s subcommands start to have trouble. So I would still highly recommend using mint for both the target and product (if you want to start exposing it as a product).
There was a problem hiding this comment.
Interesting. What sort of subcommands have trouble?
There was a problem hiding this comment.
describe, dump-package, etc.
| $ brew install mint | ||
| ``` | ||
|
|
||
| ### Make | ||
|
|
||
| ```sh | ||
| $ git clone https://github.com/yonaskolb/mint.git | ||
| $ cd mint | ||
| $ git clone https://github.com/yonaskolb/Mint.git |
There was a problem hiding this comment.
I could also change the repo name to be lowercase. What do you think? I think I prefer uppercase, but could be swayed
There was a problem hiding this comment.
There is no reason not to keep the repository and package names capitalized. That is the way most projects are and I think it looks nicer.
|
To fix the issue with SwiftLint from #14, you would need to remove the |
...which is correct in SwiftLint’s case, and for the lion’s share of other tools as well. |
|
Yeah, removing that lowercase will fix other libraries. I assumed SwiftLint was capital case because the error you posted in #14 said:
|
|
That error was because the |
|
Summary of the decisions you need to make before I can do anything else. (Case‐insensitive file systems will never notice the difference no matter what you decide.)
For reference, here is the casing of the names of other Swift‐related tools, including all the tools in Mint’s read‐me:
†Wherever “Command (actual)” does not match “Command (read‐me)”, the tool appears broken on case‐sensitive file systems, since all examples in the read‐me and documentation just result in |
||||||||||||||||||||||||||||||||||||||||||
|
I would like the executable to be lowercase. If it's possible to still have the target name be capitalised in SPM that's great, otherwise it's ok to sacrifice that and also make it also lowercase. In terms of parsing the executable name, we should just leave the value untouched instead of lowercasing it. If we don't find the command with the casing given, we should try using lowercase. |
|
The target name is capitalized again. It is an internal detail, so if problems arrive in the future, it will not be a breaking change to conform it to the executable name. The executable name of a given tool is now presumed to be exactly the same as the package name. It turns out trying fallback names (i.e. lowercase) would require a severe refactor, because right now the |
| $ mint install yonaskolb/xcodegen # use newest tag | ||
| $ mint run yonaskolb/xcodegen@1.2.4 # run 1.2.4 | ||
| $ mint run xcodegen # use newest tag and find xcodegen in installed tools | ||
| $ mint install yonaskolb/XcodeGen@1.2.4 "XcodeGen --spec spec.yml" # pass some arguments |
There was a problem hiding this comment.
It reminds me to do the same lowercase product in XcodeGen 👍
| - [yonaskolb/SwagGen](https://github.com/yonaskolb/SwagGen) | ||
| - $ mint run [realm/SwiftLint](https://github.com/realm/SwiftLint) swiftlint | ||
| - $ mint run [JohnSundell/Marathon](https://github.com/JohnSundell/Marathon) | ||
| - $ mint run [yonaskolb/XcodeGen](https://github.com/yonaskolb/XcodeGen) |
Fixes #14.
Actually, since there are no tests, it is hard to tell if I dealt with every possible casing issue, but I did fix everything that caught my eye, and I can now guarantee that Mint can successfully run...
...which I imagine involves most operations Mint performs.