Core lib name

[6od9i]

Hello.
I think this name is "Core", is abstract for specific library, maybe you can rename it to Web3Core or something?
Please

[yaroslavyaroslav]

I doubt so, this unfortunately would broke a lot of the stuff for a users as well within the library itself.

[yaroslavyaroslav]

But there's a good news, since Swift 5.7 your able to do dependencies aliasing.

Here's the code example:

 targets: [
  .executableTarget(
    name: "App",
    dependencies: [
     .product(name: "Game", package: "swift-game", moduleAliases: ["Utils": "GameUtils"]),
     .product(name: "Utils", package: "swift-draw"), 
   ])
 ]

[6od9i]

Perfect, if you use SPM, and not cocoapods

[yaroslavyaroslav]

Cocoapods are the cause of not only just this issues, unfortunately. For example: Cocoapods version of our lib uses outdated BigInt library version toward SPM one, because its just haven't been updated there, and looking up to their issues seems like it wouldn't be ever updated, while in further development we would rely on theirs new API much more broadly, which would made Cocoapods version even less stable as it is now.

The main lack of Cocoapods for us here is that it doesn't support modularity in a way that SPM does, and it does[n
t] that by design, which leads that there's a nasty hacks required to make it works there.

Worth to say, that more granular modularity is actually are one of the main request from within the active community members in Discord during that 6 months 3.0.0 pre releases period, so it'd be only increase on time.

So we'd deliver 3.0.0 branch on Cocoapods just for that: to let our Cocoapods users to easily migrate on both our new major version and to SPM as their dependency manager.

So with respect the aforesaid we'd strongly suggests you and all Cocoapods folks to migrate up to SPM in their own tempo within 3.*.* branch, since both this is the last major version of a lib that will be support it, and its support will be limited even within current version.

[6od9i]

ok, go to spm