Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SPM Support #369

Closed
mariohahn opened this issue Apr 25, 2022 · 8 comments
Closed

Add SPM Support #369

mariohahn opened this issue Apr 25, 2022 · 8 comments
Assignees

Comments

@mariohahn
Copy link

In addition to Cocopods it would be great to also support Swift Package Manager.

Thx for the lib. 🎸

#325

@jmcnamara
Copy link
Owner

There is already a Swift package for libxlsxwriter: https://swiftpackageregistry.com/damuellen/xlsxwriter.swift

@jmcnamara jmcnamara self-assigned this Apr 25, 2022
@jmcnamara
Copy link
Owner

@mariohahn Is the linked package sufficient. Can this request be closed?

@jmcnamara
Copy link
Owner

Closing.

@willm132
Copy link

There is already a Swift package for libxlsxwriter: https://swiftpackageregistry.com/damuellen/xlsxwriter.swift

This does not work or compile so that is not sufficient

@jmcnamara
Copy link
Owner

jmcnamara commented May 12, 2022

@willm132 You need to take that up with the Swift Package maintainer. There isn't anything I can do about it.

@orchetect
Copy link

orchetect commented May 28, 2024

Just FYI: the release tags for the repo are not compatible with SPM. Which greatly limits the ability to use the library as a Swift package. SPM looks for SemVer tags (ie: "1.1.7"), so it won't understand "RELEASE_1.1.7"

This is causing showstopping issues in an open-source project I'm working on. The only current solution is to fork the repo and re-tag which is not really sustainable.

If the library is used as a dependency in an app then it may be possible to just use main branch or a specific tag. But It cannot be used as a dependency within another Swift package because Xcode will not compile, citing an unstable dependency.

The easiest resolution would be to tag the repo as SemVer instead of "RELEASE_x.x.x". If that's not viable, then tagging the repo twice would work fine, one tag as SemVer and the other as "RELEASE_x.x.x".

@jmcnamara
Copy link
Owner

SPM looks for SemVer tags (ie: "1.1.7"), so it won't understand "RELEASE_1.1.7"

Does it have to be "1.1.7" or can it be "v1.1.7".

@orchetect
Copy link

Does it have to be "1.1.7" or can it be "v1.1.7".

Ideally "1.1.7", but "v1.1.7" is also recognized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants