[Quickie] Possible to tag a new release from the main branch?

[furby-tm]

Hey there!

I'd like to set a package dependency on swift-bundler from my MetaverseKit Package, so that consumers of my package can transitively use swift-bundler as a swift build tool plugin using swift package plugin bundler. Specifically, I'm looking to use it to bundle visionOS apps, but there is no tagged version incorporating those changes as of yet, and since I expect this package to grow in popularity given it's the central core dependency for powering the initial working support of Pixar's USD for Swift package, I'd like to ensure I'm pulling from the official source, which is you @stackotter!

SwiftPM is quite strict about versioning, so if I were to tag a dependency on the bundler at the main branch, then it would wreak havoc for consumers depending on my package which I'd certainly like to avoid.

Thanks!

[furby-tm]

Actually, it appears v2.0.4 has never been usable by SwiftPM due to the swift-argument-parser dependency being set to the main branch at the time:

Computing version for https://github.com/stackotter/swift-bundler.git

error: Dependencies could not be resolved because package 'swift-bundler' is required using a stable-version but 'swift-bundler' depends on an unstable-version package 'swift-argument-parser' and root depends on 'swift-bundler' 2.0.4..<3.0.0.
'swift-bundler' {2.0.4..<2.0.5, 2.0.6..<3.0.0} cannot be used because package 'swift-bundler' is required using a stable-version but 'swift-bundler' depends on an unstable-version package 'swift-argument-parser'.
'swift-bundler' {2.0.4, 2.0.6..<3.0.0} cannot be used because no versions of 'swift-bundler' match the requirement 2.0.6..<3.0.0 and package 'swift-bundler' is required using a stable-version but 'swift-bundler' depends on an unstable-version package 'swift-argument-parser'.

However, for this package to resolve without SwiftPM rejecting it, it looks like all that is needed is to:

• change branch: "main" to from: "0.5.5" for the TOMLKit package in the current configuration below:

swift-bundler/Package.swift

Line 15 in 7875559

.package(url: "https://github.com/LebJe/TOMLKit", branch: "main"),

And that should clear it up to tag a new release, I have issued a PR with this small change below.

[stackotter]

First up, thank you for using Swift Bundler!

Unfortunately (for tagging) I’m currently working towards a release which I’d like to have automatic code signing (like Xcode) and maybe a way to generate archives for uploading to the App Store, so I’d prefer not to tag it right now. Would it work for now if you instead depended on a specific commit?

[furby-tm]

That all sounds wonderful! Yes, do not tag a release if it would impede this packages ability to implement the above --

And, ah! I did not know that was possible to do with SwiftPM, do you know if there are any adverse effects to consumers of a package, the package in question depending on a specific commit hash of one of its package dependencies?

[stackotter]

I don't think it has any effects? But I would have to check (won't be able to check until Monday cause I'm away from my laptop though)

[furby-tm]

No need to worry; I plan to address this before the end of the day and will inform you if any issues arise with pinning a specific commit hash.

While directly incorporating package dependencies into your own package with SwiftPM is generally straightforward, it can become somewhat challenging when dealing with products from packages intended for consumption by other packages.

The observed behavior in this case illustrates the somewhat stringent versioning requirements imposed by SwiftPM.

---

Furthermore, while this isn't directly tied to the current issue,
I'd like to bring it up here to prevent unnecessary issue ticket
creation. In the context of my work on the MetaverseKit package,

I've developed a basic yet functional ImGui Swift target
(still requires a small amount of work to offer the full scope
of the ImGui API), but it's something I plan on rounding out over
the course of the next month.

I'm contemplating creating a separate Swift package for it and
wanted to inquire whether you think it could be beneficial for
use with your Swift Cross UI project.

[stackotter]

The observed behavior in this case illustrates the somewhat stringent versioning requirements imposed by SwiftPM.

Yeah SwiftPM can be pretty annoying about versioning.

I'm contemplating creating a separate Swift package for it and
wanted to inquire whether you think it could be beneficial for
use with your Swift Cross UI project.

It could be interesting to try implementing an experimental ImGui backend for SwiftCrossUI at some point, but I'm not planning on doing that anytime soon so don't worry about making it a separate package if it's a hassle. ImGui follows a very different paradigm to the frameworks which I've built backends for so far, and it'd be pretty difficult to retrofit it in.

[furby-tm]

Update, finally got around to whipping up a simple command line plugin for the bundler:
#36

[furby-tm]

The ability to follow the strict versioning requirements of SwiftPM have been resolved with #36