Charts
Charts copied to clipboard
Conflict with Apple's Swift Charts
Is anyone else having issues while doing
import Charts
in SwiftUI ? It am trying to use Apple's Swift Charts (iOS 16 only) but it can't compile, I presume because the import statement is interpreted as targeting this library and not Apple's Swift Charts as I want to.
Any fix, workaround or way to specify better what to import is welcomed, haven't found any other solution than nuking this library from my project, however I would need it for users with iOS 15 or less.
What did you do?
Tried to use Apple's Swift Charts in some SwiftUI view in my app that uses this Github repo (https://github.com/danielgindi/Charts) in other places of the app, installed via cocoa pods.
I naturally do
import Charts
to import Apple's library, however it seems the compiler does not understands it that way as I can not use Swift Charts's charts in my SwiftUI struct view.
What did you expect to happen?
I expected this Chats library to not interfere.
What happened instead?
I seem to be unable to use Swift Charts because of this library
This is because module name collision - this library uses the same module name that is used by new Swift Charts framework (available since iOS 16.0, mac OS 13.0).
Workaround:
- fork repo
- add
s.module_name = 'DGCharts'
to podspec in your repo - in the Podfile specify your fork
- replace your
import Charts
statements withimport DGCharts
To resolve this issue:
- repo owner should decide on module prefix (I used
DGCharts
as reference to Daniel Gindi as repo owner) - change podspec, library name (maybe), and import statements in library (tests) accordingly
related to #4845
hey, I'm having the same issue when using SPM. Is there a similar workaround for SPM?
I modified Package.swift as below and compiled successfully by changing the import to DG Charts.
If I then add Import Charts to pull in the Swift charts I get a conflict elsewhere with the following message.
'PieChartDataEntry' is ambiguous for type lookup in this context
Any ideas what I can do?
// swift-tools-version:5.1
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "DGCharts",
platforms: [
.iOS(.v12),
.tvOS(.v12),
.macOS(.v10_12),
],
products: [
.library(
name: "DGCharts",
targets: ["DGCharts"]),
.library(
name: "ChartsDynamic",
type: .dynamic,
targets: ["DGCharts"])
],
dependencies: [
.package(url: "https://github.com/apple/swift-algorithms", from: "1.0.0")
],
targets: [
.target(
name: "DGCharts",
dependencies: [.product(name: "Algorithms", package: "swift-algorithms")],
path: "Source/Charts"
)
],
swiftLanguageVersions: [.v5]
)
ok, it was simple. It needs to be called explicitly with DGCharts.PieChartDataEntry
@pmairoldi @danielgindi @jjatie shall we change the name to DG-iOS-Charts or similar to address the naming issue officially ? just decide an official name so we can continue?
I think that DGCharts would be the most appropriate. Back to the old Objc way of meaning :p. I think we should make this a major release though.
I think that DGCharts would be the most appropriate. Back to the old Objc way of meaning :p. I think we should make this a major release though.
+1. Let's do it, if no body objects, like after a month?
This would be very useful 🙏
Why wait a month? It's been months already since Apple's native Charts library has been released.
No one's going to object. On the contrary, people have been clamoring for this for a while.
It might not take a month but we are giving ourselves time since we don’t do this full time. There is more to it than just renaming. We have to update all the docs in all languages, make sure the sample projects still all work, and maybe contact the people who made tutorials we link to in our readme to update their articles.
That's a very fair point. Looking forward to the new release!
sorry. I already saw #5009 working on this.
I think your #5009 is on the right rack but the name can't be UI prefixed. Let's rename to DGCharts and I'm willing to make #5009 merged as my 1st priority. and thanks @waterskier2007 for your effort!
I updated #5009
I believe this could also be temporarily solved using the Swift 5.7 module alias feature
https://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md
This is what I proposed to solve this problem a while ago but issues keep coming up so we are going to change the name.
I haven’t pushed it yet but I’ve basically finished the renaming. I just need to validate that all build tools keep working.
I believe this could also be temporarily solved using the Swift 5.7 module alias feature
https://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md
Yeah that could help on some projects, however all of the times I looked in to it, it really appears that Xcode doesn't have great support for module aliasing.
Closed by #5027