In Clean Architecture by Robert C. Martin the dependency rule points strictly from the outermost layer/ring to the innermost.
As an example a Dependency Injection Framework should lie on the outermost layer (frameworks) to allow for it to be replaced.
However, a DI framework which relies on attributes would clearly break this, as any class which would require those attributes would have a dependency on the framework. Therefore such a library could not be used following the dependency rule strictly.
I am running into the same problem with utility libraries, e.g. a Math Library or some Rx library providing IObservables/Subjects.
The math library could be wrapped by an adapter to keep it replacable - which makes sense, but for example a Entity providing the framework for both entities (inner most layer) as well as systems (business rules) and maybe even UI (presenters) simply does not go well with this design.
However, even for the math library the cost of adding the interfaces for Dependency Inversion+Adapter sounds pretty insane.
Am I missing something or is this more or less a rule which commonly break when trying to implement