dockutil
dockutil copied to clipboard
kcrawford
Add Swift Package Manager support
- Add Swift Package support
- Update file structure to standard swift package
- Fix SPM warning
https://www.swift.org/package-manager/
After the change, we can just use swift build to get the executable, swift run to run it and swift test to run tests.
And other swift package or swift package plugin can depend on this.
This PR does not remove Xcode project support and change the release workflow.
@kcrawford Could you help review this in your spare time? Some downstream needs SPM support. ❤️
@kcrawford many people would like to use this beautiful utility you created, but they can't without easy installation way (i.e. Homebrew).
Please, take a look at this PR, it will help so many users of your dockutil
I'd like to bump this? The version of Dockutil in Homebrew is out of date and unusable, and this is blocking https://github.com/Homebrew/homebrew-core/pull/97394 to get this updated.
Could a community member maybe get access to merge some of these pull requests? I would do it if I was a developer, but you don't want me with those keys. @kcrawford
@Kyle-Ye would you be interested if @kcrawford responds?
It may just be time to fork this project and move on, doesn't look like @kcrawford has been active in over a year.
Could a community member maybe get access to merge some of these pull requests? I would do it if I was a developer, but you don't want me with those keys. @kcrawford
@Kyle-Ye would you be interested if @kcrawford responds?
Yes, I'm fine to keep the project moving on.
I’m sorry for the delays. I don’t want to merge something I don’t understand as I have to maintain this going forward. I haven’t yet made time to understand this and why alternatives weren’t chosen to solve homebrew compatibility. I’ll try to look into it as soon as I have some time. If anyone can point me to more info on why this is the best/standard way to handle open source swift projects and homebrew I’d appreciate it. Can you also briefly explain why a pkg doesn’t work for your use case. I’m not trying to be difficult—I genuinely don’t understand and that’s probably a reason this has been neglected.
I’m sorry for the delays. I don’t want to merge something I don’t understand as I have to maintain this going forward. I haven’t yet made time to understand this and why alternatives weren’t chosen to solve homebrew compatibility. I’ll try to look into it as soon as I have some time. If anyone can point me to more info on why this is the best/standard way to handle open source swift projects and homebrew I’d appreciate it. Can you also briefly explain why a pkg doesn’t work for your use case. I’m not trying to be difficult—I genuinely don’t understand and that’s probably a reason this has been neglected.
@kcrawford If you have your time available, you can spend some time checking the following posts.
https://github.com/orgs/Homebrew/discussions/59
https://github.com/Homebrew/homebrew-core/pull/97394
Thanks @Kyle-Ye. I was able to build from your branch using swift build, but building from Xcode failed for me (Info.plist not found, 'XCTestSwiftSupport', 'XCTest' not found) and top level directories and files like Sources and Package.swift are not visible in Xcode. I don't like the duplicated hard-coded VERSION though I see the reason. Do you think we can make this look and act like a fresh new Swift Package from Xcode Template so Xcode handles it as expected. Maybe starting with that and adding in the classes would be cleaner.
Got it, I'll update the commits and make it ready for review once it's done. @kcrawford
But I have 2 questions:
- Should we still preserve .xcodeprojc support / provide support for both Xcode project and Swift Package? IMO, the answer is NO.
- Should we still use info.plist to store the version information? Swift Package Manager currently does not have a very support support for custom Info.plist.
A workaround is discussed here https://forums.swift.org/t/swift-package-manager-use-of-info-plist-use-for-apps/6532/13
- Should we still preserve .xcodeprojc support / provide support for both Xcode project and Swift Package? IMO, the answer is NO.
Being new to Swift Package development I don't know the implications of this. I'd want full Xcode support.
- Should we still use info.plist to store the version information? Swift Package Manager currently does not have a very support support for custom Info.plist.
Again I don't know, but I'd want minimal workarounds. Having info.plist support seems important.
It may make sense for me to attempt the conversion to Swift Package just so I feel comfortable with the changes.
Thanks @Kyle-Ye. I was able to build from your branch using swift build, but building from Xcode failed for me (Info.plist not found, 'XCTestSwiftSupport', 'XCTest' not found) and top level directories and files like Sources and Package.swift are not visible in Xcode. I don't like the duplicated hard-coded VERSION though I see the reason. Do you think we can make this look and act like a fresh new Swift Package from Xcode Template so Xcode handles it as expected. Maybe starting with that and adding in the classes would be cleaner.
- Fixed the Info.plist not found and XCTest import issue on xcodeproj.
- The version info in Info.plist is $(CURRENT_PROJECT_VERSION) which is defined on .xcodeproj file. So even we force inserting Info.plist to SPM system. We still can't get the info on .xcodeproj file. IMO, there is really no reason to preserve .xcodeprojc support. Once we drop xcodeproj support. There will be no duplicated hard-coded VERSION issue left.
@kcrawford, can you please review/merge this PR?
Is there a CI pipeline for this project somewhere? If there isn't, I can try to create one using GitHub Actions and/or Cirrus CI.
PS: GitHub Actions Workflow PR is now at https://github.com/kcrawford/dockutil/pull/152.
Homebrew just recently marked dockutil as deprecated. That's going to significantly reduce the number of people able to use dockutil. That's a shame, because it's a great little utility. I use it in my Mac setup scripts. Merging this is probably the only hope to fix that.
@kcrawford is there any chance you could find time to review this patch? Lots of folks want to use dockutil through Homebrew, and this is blocking them from doing so. As @booch said, this is a neat tool and it would be great if more folks could benefit from your work. I'm sure there are volunteers in this thread or in the Homebrew thread that would be happy to help you with anything you need to accomplish this if you respond.
I have created a fork and release 3.0.3 to add SwiftPM build support.
Are there any HomeBrew volunteer who would like to help reopen a HomeBrew PR against my fork? - https://github.com/Kyle-Ye/dockutil/releases/tag/3.0.3.
https://github.com/Homebrew/homebrew-core/pull/97394 cc @sashkab
It is still my intention to implement this. Just want to become familiar with it and haven’t had time. Hopefully will get to it soon. I feel terrible that it is taking so long.
Hi @kcrawford, I just want to make sure you're aware that the HomeBrew project has now marked your project as "deprecated." I just noticed this. I'm not involved with Homebrew, but I really hope you can fix this before they remove Dockutil entirely. I bet a lot of your users find and install this via Homebrew. Is there any chance you could either make this a priority or add someone else as a maintainer to get this resolved? I'd be happy to volunteer, and I'm sure others would be as well.
Sorry for all the delays. Wanted to be sure I could support this going forward.
Approving this to more forward with Swift Package Manager. I expect some issues but we'll work through them.
If there are items I could help, feel free to assign it to me.
@kcrawford First of all, thank you for merging this. So that all of us home-brew users can use your fantastic tool through that, would you mind cutting a new release? Homebrew usually indexes off of releases rather than HEAD. It looks like @chenrui333 created a separate issue for this. https://github.com/kcrawford/dockutil/issues/158
I have to figure out how I want to build, sign, notarize the .pkg with the change. I think if I do a release without a pkg it may break autopkg recipes or other automation scripts looking for a pkg associated with the release.
I have to figure out how I want to build, sign, notarize the .pkg with the change. I think if I do a release without a pkg it may break autopkg recipes or other automation scripts looking for a pkg associated with the release.
@kcrawford Thank you for explaining. Do you have an ETA on when this will be done?
@Kyle-Ye @chenrui333 @rgl do any of you have advice on how to do this? Perhaps you can help @kcrawford if you know.
Working on a new release but noticed my Apple Developer subscription expired. Wanted to let folks know that you or your company can contribute to this project using the sponsor button.
Regardless I hope to have a release out soon.