The xcframework supports archive formats, such as `.zip`, `.tar`... about tuist HOT 5 CLOSED

I think this makes sense. I'd be curious why you don't unarchive the .xcframework in the filesystem before running tuist generate? Just to understand a bit better where this comes from 🙂

I agree with @fortmarek here. How a portable binary is transported/stored (e.g., in a zip file) is not something Tuist should be concerned about. If we bring that responsibility into Tuist, we open the door for feature requests to support the infinite options out there, and it'll distract us from other areas of the project that would benefit from deeper focus.

Is there any concern with unzipping it yourself @Binlogo ?

No, I resolved the issue by unzipping the file first. It's fine with me, not a major issue.

As I mentioned early, when I first encountered Tuist, its design and syntax reminded me of (SPM), leading me to expect that it would function in a similar manner.

However, if ensuring compatibility with zipped files is not within Tuist's scope, then perhaps my expectations may need adjustment.

from tuist.

Hey 👋

Detect the path provided, determine its format to unarchive if needed.

I think this makes sense. I'd be curious why you don't unarchive the .xcframework in the filesystem before running tuist generate? Just to understand a bit better where this comes from 🙂

from tuist.

I think this makes sense. I'd be curious why you don't unarchive the .xcframework in the filesystem before running tuist generate? Just to understand a bit better where this comes from 🙂

🤔 The scenery is the .zip file used for SPM originally. When migrating to use Tuist, using the .zip file directly is a nature path until tuist generate fails. Then I realize Tuist only support unarchived .xcframework itself.

from tuist.

The scenery is the .zip file used for SPM originally.

Is the .zip downloaded by SPM?

When migrating to use Tuist, using the .zip file directly is a nature path until tuist generate fails. Then I realize Tuist only support unarchived .xcframework itself.

How does Xcode deal with linking against an .xcframework archive?

All-in-all, I'm not against this feature, that being said, it might be on you (or someone from the community) to take this on as it's unlikely we'll get to this ourselves.

from tuist.

I think this makes sense. I'd be curious why you don't unarchive the .xcframework in the filesystem before running tuist generate? Just to understand a bit better where this comes from 🙂

I agree with @fortmarek here. How a portable binary is transported/stored (e.g., in a zip file) is not something Tuist should be concerned about. If we bring that responsibility into Tuist, we open the door for feature requests to support the infinite options out there, and it'll distract us from other areas of the project that would benefit from deeper focus.

Is there any concern with unzipping it yourself @Binlogo ?

from tuist.