For some reason the module name of ReachabilitySwift has been renamed to Reachability.
Unfortunately those both projects now collide if included in one project. This mainly happens if third party dependencies are using pulling each dependency in. (See the attached example project)
I would strongly suggest to move back to the old "ReachabilitySwift" module name to avoid this issue.
Thanks for raising this issue, but backwards compatibility with Objective C / mixed projects is a non-goal for this library.
Cheers
Ash
Hi @ashleymills
I am having same problem, getting conflicts about other libraries
ReachabilitySwift and Reachability
is there any alternative to make it work?
in Xcode side?
I did research some solutions but I don't really understand it.
they said that Rename the file.
can you provide a solution?
Well, you're publishing a free library than tons of people use and has certainly helped the community in many ways so I should start off with that thanks (I'm more forced to use it as a transient dep and others' decisions/inclusions, but no need to dive into that, I still do want to express my gratitude for your creation, maintenance, and sharing of a library that has helped the community, a huge thanks for that!!!).
I would suggest that this is not a question of so much "backwards compatibility" as much as "respect convention and norm" by using a unique identifier in front of the module name (especially when it collides with a well-known existing or platform-provided one!), and even more-so when creating something that's no doubt going to become a transient dependency.
A year later almost, this problem persists, and forces developers and users to resort to chicanery which largely defeats the whole purpose or advantage of open-source software when the problem is largely preventable.
What would be so offensive about ASHReachability? The chances of a namespace collision are incredibly lower. And you have a cool first name, too!
I didn't choose for graphql_flutter and connectivity to use ReachabilitySwift and Reachability (respectively) and result in an awkward build error that forces me into weird undulations that more resemble poses named after ancient sanskrit than reasonable, modern solutions, yet here we are, many of us (if my GH searches, etc are any indication), simply because a name wasn't chosen uniquely when trying to improve another?
Sure, I'll fork either ReachabilitySwift and fix the issue or graphql_flutter and have it use connectivity_swift instead, but doesn't that run anathema to the whole open source, shared contribution model? I'd rather spend the time we are invariably going to now spend maintaining that (that's inevitably going to break at some point) contributing to advancing your project or another than working around a name that is absurdly chosen, why?
Again, not to sound offensive (my intent is not that at all), but to seriously question the wisdom on a purely technical merit of knowingly inciting namespace and symbol collision, and the further doubling down to that end in the name of what, exactly?
PS - Yes, I know the irony of an American saying things like "respect convention and norm" and "we all should play well with others", and "why double down on the wrong decision" is not lost on me, but you know, "not my President" and I am sorry for the 63M idiotic countryfolk of mine that still drag their knuckles...
Thanks for raising this issue, but backwards compatibility with Objective C / mixed projects is a non-goal for this library.
Cheers
Ash
Most helpful comment
Well, you're publishing a free library than tons of people use and has certainly helped the community in many ways so I should start off with that thanks (I'm more forced to use it as a transient dep and others' decisions/inclusions, but no need to dive into that, I still do want to express my gratitude for your creation, maintenance, and sharing of a library that has helped the community, a huge thanks for that!!!).
I would suggest that this is not a question of so much "backwards compatibility" as much as "respect convention and norm" by using a unique identifier in front of the module name (especially when it collides with a well-known existing or platform-provided one!), and even more-so when creating something that's no doubt going to become a transient dependency.
A year later almost, this problem persists, and forces developers and users to resort to chicanery which largely defeats the whole purpose or advantage of open-source software when the problem is largely preventable.
What would be so offensive about ASHReachability? The chances of a namespace collision are incredibly lower. And you have a cool first name, too!
I didn't choose for graphql_flutter and connectivity to use ReachabilitySwift and Reachability (respectively) and result in an awkward build error that forces me into weird undulations that more resemble poses named after ancient sanskrit than reasonable, modern solutions, yet here we are, many of us (if my GH searches, etc are any indication), simply because a name wasn't chosen uniquely when trying to improve another?
Sure, I'll fork either ReachabilitySwift and fix the issue or graphql_flutter and have it use connectivity_swift instead, but doesn't that run anathema to the whole open source, shared contribution model? I'd rather spend the time we are invariably going to now spend maintaining that (that's inevitably going to break at some point) contributing to advancing your project or another than working around a name that is absurdly chosen, why?
Again, not to sound offensive (my intent is not that at all), but to seriously question the wisdom on a purely technical merit of knowingly inciting namespace and symbol collision, and the further doubling down to that end in the name of what, exactly?
PS - Yes, I know the irony of an American saying things like "respect convention and norm" and "we all should play well with others", and "why double down on the wrong decision" is not lost on me, but you know, "not my President" and I am sorry for the 63M idiotic countryfolk of mine that still drag their knuckles...