Comments (2)
Hey @sovata8 👋
Can you post a reproducible project that you worked with? Have you run tuist install
after adding the dependency in your Tuist/Package.swift
?
You can check out our fixture that showcases how to integrate dependencies via the XcodeProj-based integration: https://github.com/tuist/tuist/tree/main/fixtures/app_with_spm_dependencies
from tuist.
Hi, thanks for the reply.
The link to the sample project was a great resource!
I took it and reduced it to exactly my reproducible case, and can now observe where things fail.
I am attaching both my sample minimal reproducible project, and the modified Tuist's app_with_spm_dependencies
.
tl;dr:
Things work only if the Alamofire package is defined under MyApp's Package.swift - if we define it in MyFramework's Package.swift, tuist-generate only works from the framework's folder, but fails for the whole app. Provided only MyFramework needs to know about the external dependency, ideally we'd like to define the it under MyFramwork, not globally.
The findings
(The explanation here applies to both attached projects, they have been reduced to the same reproducible issue)
So, in both projects MyApp -> MyFramework -> Alamofire
.
Both MyApp and MyFramework have a Project.swift
.
MyApp
does not depend on 'Alamofire' (directly) only on MyFramework
.
(Note, this is different from the original app_with_spm_dependencies
where both the App and FeatureOne depend directly on Alamofire)
MyFramework's 'Project.swift' has as a target dependency:
.project(target: "FeatureOneFramework_iOS", path: .relativeToRoot("Features/FeatureOne"))
MyFramework's 'Project.swift' has as a target dependency:
.external(name: "Alamofire")
When it works and when it doesn't
We need to define the Alamofire package somewhere:
.package(url: "https://github.com/Alamofire/Alamofire", exact: "5.8.0")
If we define it under MyApp/Tuist/Package.swift
, things work perfectly - the project generates, builds and runs. Alamofire is only linked to MyFramework as it should. We can also generate and build just MyFramework's project from its own folder, which is great.
But the above is somewhat confusing / unexpected / not ideal - by defining he package in the main app's Tuist/Package.swift
, we make a 'hidden' dependency of MyFramework on a Tuist package defined under MyApp. Indeed, if we take this framework folder and put it elsewhere on our filesystem, it won't tuist-generate anymore, because the URL for Alamofire was defined in MyApp.
Ideally, we would like to be able to define the Alamofire package under MyFramework/Tuist/Package.swift
.
Doing this actually works fine when generating MyFramework only, from its folder.
But then if we switch to MyApp, the generation fails with:
``Alamofire is not a valid configured external dependency
Zip files
from tuist.
Related Issues (20)
- Airship/AirshipAutomation failures
- Binary caching with swift-system v1.3.0 as a dependency fails HOT 6
- tuist test compiles unrelated targets
- 'tuist cache' fails when there are targets without sources HOT 4
- Tuist rewrite GCC_PREFIX_HEADER when resource bundle synthesizer enabled ignoring user-defined values HOT 3
- The Composable Architecture compatibility issues HOT 31
- Missing logs when running `tuist test`
- Tuist Cache fails when using macros in combination with Workspace test covearge
- SkeletonView library gives error: "unrecognized selector sent to instance" HOT 5
- Tuist cloud run report shows tuist version twice HOT 3
- `.package.resolved` is not generated HOT 7
- Crash in unit tests with enforceExplicitDependencies, tuist cache and dynamic framework GRDB HOT 4
- Duplicate Symbols Issue When Using Tuist with Multiple Frameworks HOT 19
- error: external macro implementation type 'ComposableArchitectureMacros.ReducerMacro' could not be found for macro 'Reducer()' HOT 1
- 'swift' command exited with error code 1 on install
- Mergeable Libraries not reexported
- When using `DefaultSettings.essential` mergeable libraries build settings not set
- Using `MergedBinaryType.manual` overrides Other Linker Flags HOT 2
- `tuist init` DX HOT 3
- [Feature Proposal] Conventionally default `CURRENT_PROJECT_VERSION` to `CFBundleVersion` HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tuist.