Cargo uses feature unification during dependency compilation. During feature unification, cargo determines the union (set theory edition) of all the features set for a given crate and compiles one version of that library with those features enabled. The top level crate or workspace then is linked against this unified library.
From the docs:
A consequence of this is that features should be additive. That is, enabling a feature should not disable functionality.
At the moment, enabling the library feature removes the entry module from the contract. This violates the assumption cargo makes about features and results in a position where it is impossible to both use cw721_base in [dependencies] and use it in multitest.
Reason being that when cargo sees something like:
[dependencies]
cw721-base = { version = "0.13.4", features = ["library"] }
[dev-dependencies]
cw721-base = "0.13.4"
It does feature unification causing the test build to have the library feature thus preventing us from using the provided execute methods.
Cargo uses feature unification during dependency compilation. During feature unification, cargo determines the union (set theory edition) of all the features set for a given crate and compiles one version of that library with those features enabled. The top level crate or workspace then is linked against this unified library.
From the docs:
At the moment, enabling the
libraryfeature removes theentrymodule from the contract. This violates the assumption cargo makes about features and results in a position where it is impossible to both usecw721_basein[dependencies]and use it in multitest.Reason being that when cargo sees something like:
It does feature unification causing the test build to have the
libraryfeature thus preventing us from using the provided execute methods.