Suppose we are second normal form with:
R(a,b,c,d,e)
FD: (a->bcde, c->de, d->e)
And we remove transitive dependencies:
R1(a,b,c)
R2(c,d,e)
R3(d,e)
Is this a correct decomposition?
Related
I have a scala project which has scalatest enabled:
testFixturesImplementation("org.scalatest:scalatest_${vs.scalaBinaryV}:${vs.scalaTestV}")
This introduces scala-xml 2 as a dependency:
org.scalatest:scalatest_2.12:3.2.12
org.scala-lang:scala-library:2.12.15
org.scalatest:scalatest-core_2.12:3.2.12
org.scala-lang:scala-library:2.12.15
org.scalatest:scalatest-compatible:3.2.12
org.scalactic:scalactic_2.12:3.2.12
org.scala-lang:scala-library:2.12.15
org.scala-lang:scala-reflect:2.12.15
org.scala-lang:scala-reflect:2.12.15
org.scala-lang.modules:scala-xml_2.12:2.1.0
Unfortunately it is in conflict with the json4s-jackson library I used for testing, which relies on scala-xml 1, and even if I declare scala-xml 1 everywhere:
constraints {
api("org.scala-lang.modules:scala-xml_2.12:1.0.6")
testImplementation("org.scala-lang.modules:scala-xml_2.12:1.0.6")
testRuntimeOnly("org.scala-lang.modules:scala-xml_2.12:1.0.6")
}
api("org.scala-lang.modules:scala-xml_2.12:1.0.6")
testImplementation("org.scala-lang.modules:scala-xml_2.12:1.0.6")
testRuntimeOnly("org.scala-lang.modules:scala-xml_2.12:1.0.6")
It is still being omitted, and scala-xml 2 is always chosen (see last line):
org.json4s:json4s-jackson_2.12:3.5.3
org.scala-lang:scala-library:2.12.3 ➡ 2.12.15
org.json4s:json4s-core_2.12:3.5.3
org.scala-lang:scala-library:2.12.3 ➡ 2.12.15
org.json4s:json4s-ast_2.12:3.5.3
org.scala-lang:scala-library:2.12.3 ➡ 2.12.15
org.json4s:json4s-scalap_2.12:3.5.3
org.scala-lang:scala-library:2.12.3 ➡ 2.12.15
com.thoughtworks.paranamer:paranamer:2.8
org.scala-lang.modules:scala-xml_2.12:1.0.6 ➡ 2.1.0
What can be done to avoid this without using shadowing? What's the possible cause of this?
I need to reuse local Swift packages in multiple targets. They are all part of the same workspace which looks something like this
- Workspace
- ProjectA
- TargetA1 depends on PackageA
- TargetA2 depends on PackageA and PackageB
- ProjectB
- TargetB1 depends on PackageA
- ProjectC, etc...
- Modules
- PackageA
- PackageB
The package build products are added under the individual targets General > Frameworks and Libraries dependencies. Now when I trigger the build, I get
Multiple commands produce '.../Modules/PackageA' etc...
which is somewhat understandable, I hoped Xcode would be smart enough to not build the package over and over again, and even if, I don't understand why that would result in an error in the first place.
Is there a reasonable solution to this?
I don't want to start creating static library targets again or create a separate repository just to be able to import it via a package dependency.
Ok, I found a somewhat satisfactory answer to this.
First, prevent SPM from choosing the library type itself and declare 2 separate build products in the package you want to share:
...
products: [
.library(name: "PackageA", type: .dynamic, targets: ["PackageA"]),
.library(name: "PackageAStatic", type: .static, targets: ["PackageA"])
],
...
One explicitly .dynamic and the other explicitly .static. Now depending on the target you want to use this package in, link the correct one (either dynamic or static). This seems to resolve this issue for me.
I have project structure
-core_data
-core_domain
-core_ui
-core_launcher
The dependency of these 4 projects is
core_launcher -> core_ui -> core_domain -> core_data
4 projects are located in the same directory and I include one to another via pubspec.yaml file (for example core_launcher/pubspec.yaml):
dependencies:
flutter:
sdk: flutter
core_ui:
path: ../core_ui
The same thing I do with all projects to make dependency hierarchy.
The problem is that I can import all files from core_ui subproject when I'm currently editing some file in core_launcher but VSCode doesn't see any classes from his parents
(core_domain & core_data).
However, I can input import 'blah-blah-blah manually and VSCode see this class and import works well, but I can't do that with hit Alt+Enter that I do for fast-import.
So, I'm wondering why autocomplete is not working for inherited libraries.
Somebody had the same issue?
Code completion will only show classes from your direct dependencies. There are two possible reasons for this:
Relying on transitive dependencies is not a good idea, because it's possible that your dependencies will remove or change their dependencies and not consider that a breaking change.
If code completion listed all classes from all transitive dependencies the code completion list would be huge and include classes from packages you do not recognise (because they are just other packages dependencies). This would be a bad user experience and make it easy to accidentally rely on packages that are not listed in your pubspec.yaml.
The fix is to explicitly list core_domain and core_data in your pubspec.yaml too, because if your project is using classes from them, then they are dependencies.
Given my bog standard Package Description of
let package = Package(
name: "MyLib",
products: [
.library(name: "MyLib", targets: ["MyLib"]),
],
dependencies: [],
targets: [
.target(
name: "MiniRxSwift",
dependencies: [],
swiftSettings: [
.define("<see below>")
]),
...
I'm trying to get swiftpm to pass the -enable-library-evolution flag through to swiftc, but I've been unsuccessful.
Using swiftSettings of .define("-enable-library-evolution"), I get a compile error which states
"error: conditional compilation flags must be valid Swift identifiers (rather than '-enable-library-evolution')"
I get the same error if I omit the leading hyphen e.g. `.define("enable-library-evolution")
I've tried the Xcode setting of .define("BUILD_LIBRARIES_FOR_DISTRIBUTION") which doesn't result in a compile error, but also doesn't result in the flag getting set, it instead results in -DBUILD_LIBRARIES_FOR_DISTRIBUTION on the command line for swiftc, which doesn't do anything.
After a bit more research, I worked out that .define in swiftSettings is hardwired to produce things with -D - hence it's name.
Instead I needed to use unsafeFlags, which does indeed result in the flag getting passed correctly to the swift compiler:
swiftSettings: [
.unsafeFlags(["-enable-library-evolution"])
]
BUT then when I attempt to consume this package, Xcode fails to load the package, with the error:
The package product 'MyLib' cannot be used as a dependency of this target because it uses unsafe build flags.
If I can't enable library evolution without unsafe build flags, and I can't use unsafe build flags in a library, then what can I do? What is the point of having unsafeFlags if you can't use any libraries which set them?
Why do you need ABI stability if you have access to the package? You should avoid it if possible. That said, you should be able to use unsafeFlags with editable packages (ones you have dragged into the project) but not ones you include the normal way via URL.
If you need to vend someone a swift package as a binary you will need to build your package as an XCFramework and then you can put that in a place where SwiftPM can depend on it. That means it can be hosted at a static place where you give the URL or it can be embedded in the git repo with the Package.swift manifest that you have for vending the package. The only tool I know of to help with this is found here which works for Swift only package when I have used it.
I need something similar in Dart to what Maven has with a parent-pom dependencyManagement structure.
I have 2 modules in Dart, api and core.
api/pubspec.yaml:
...
dependencies:
http: '>=0.12.0 <0.13.0'
meta: '>=1.0.0 <2.0.0'
...
core/pubspec.yaml:
...
dependencies:
api:
path: ../api
# Meta is added again with a version number
meta: '>=1.0.0 <2.0.0'
redux: '4.0.0'
...
So if I change the dependencies in core/pubspec.yaml to 'any' if they already exist in api/pubspec.yaml:
...
dependencies:
api:
path: ../api
# No version number is needed, the exact version will come from the dependency
meta: 'any'
redux: '4.0.0'
...
This seems to be working, but the official site does not mention this feature, instead:
The string any allows any version. This is equivalent to an empty version constraint, but is more explicit. Although any is allowed, we don’t recommend it.
Is this an unintended good use case of the 'any' or this is a bad idea? (I am confident api dependency will always exist and declare meta, they are all my modules.)