Adds new swift-package for use in Native projects.

[mkaulfers]

No description provided.

[sammarks]

Any way you can contribute the code of the package so it can be stored in this repository, rather than having the documentation point to yours?

[mkaulfers]

Unfortunately I don't believe there is a way. The way XCode pulls it in is via the .git url as if it was cloned. The file structure is very important for it. If any one pice is out of place, then it won't work. It looks specifically for the Package.swift file to know what the structure for it is, which is at the root.

[paescuj]

It looks specifically for the Package.swift file to know what the structure for it is, which is at the root.

I don't see a problem in adding this file in this repo here at root level 👍 In contrast, I would be a bit hesitant when it comes to including a submodule inside this repo.

[sammarks]

Perhaps you could add all of the files from your repository to the root of this one? Looks like we would just need the following files:

• Sources
• .swiftpm/xcode
• Package.swift

And then we could integrate update.sh with our internal build script that runs every time new icons are generated.

As for excluding files so this entire repository isn't cloned whenever you install via Swift Package Manager, it appears there's a mechanism for that.

I hesitate to create a separate repository for this (even in the iconoir-icons org) as syncing the tags and icons would become a bit of a chore, when we can automate it in this repo with GitHub Actions.

[paescuj]

I hesitate to create a separate repository for this (even in the iconoir-icons org) as syncing the tags and icons would become a bit of a chore, when we can automate it in this repo with GitHub Actions.

In my opinion, this doesn't sound like a bad idea. As far as I know, you can trigger other workflows within a GitHub organization. Although I don't think anything speaks against adding it to this repo here (besides polluting the root 😄).

[mkaulfers]

Well, if we add it to the top, then we have to add all of it to the top level. I'd strongly recommend against that. An alternative would be to provide a binary on your repo that can be used but then that kills the "Open Source" side of it. Unfortunately it's no simple answer and this is the solution I could come up with. I'm already working towards automating the Swift Package from within the separate repo, to always stay in sync with this repo.

[sammarks]

I trust your judgement. Do you mind creating a PR with your repository's code in this repository instead?

It would be great if you could create a GitHub Actions script that triggers your script every time the main icons are updated. If not, I'm sure we can handle it a different time.

And then if you could update this PR to include the link to the new repo.

[DaniFoldi]

Could the source of truth not be kept in (this) the main repo, and mirrored to the swift package for releases?

(Edit: keep the swift-related code in a subfolder here, and copy to the root of the dedicated repo.)

[sammarks]

I would say if we're doing the separate repository route, let's just keep things simple and keep it separated in the other repo, and just keep it in sync with the icons / releases from this one.

I'm hoping we can lean on @mkaulfers a bit here to automate that release process so it doesn't become a chore 😄

But, as always, if we find it becomes unsustainable we can always figure out how to move it to this repository later. I'm apt to go ahead and create a separate repository now since the code is already there and we can quickly get SwiftUI support out.

[mkaulfers]

@DaniFoldi @sammarks @paescuj So if I'm reading correctly, remove the iconoir-swift directory from the packages directory. Then move it over to the new repo that was created here https://github.com/iconoir-icons/iconoir-swift

[sammarks]

@mkaulfers actually:

• Keep this PR as-is, except update the link to point to iconoir-icons/iconoir-swift instead of your personal repository.
• Create a new PR for iconoir-icons/iconoir-swift with all of the contents of your personal repository. - I'm happy to do this too, but if you create a PR for it you get the credit in the commit history.
• If you have time, it would be great if you could come up with a GitHub Actions workflow to automate updating the repository and releasing new versions whenever a new version of Iconoir is released inside the main repository.

[mkaulfers]

@sammarks okay that works, but why keep the source both in here as well as the other? If Iconoir will be in posession of the source of truth, no need to have it copied in both repos right? I already have a thought for the workflow to update the repository and there already exists a update.sh script added with the package that will handle writing new code as well as downloading properly formatted icons. For sure I'd like to do it however, contributing to open source looks good at my job as well as helps keep copilot free lol

[sammarks]

I'm not sure what you mean by keeping the source in this repo as well as in the other? If you're talking about the submodule you've added inside the PR, we can get rid of that in this repo as we don't need it.

[mkaulfers]

Yes that's what I was referring to. I'll get that going here in a few minutes.

[mkaulfers]

@sammarks done 👍 There's now a PR up on both repositories, submodule has been extracted, and as soon as they're approved I'll get it listed on Swift Package Index.

[sammarks]

Thank you!