Non-compliant Namespace Package Structure

[Alex-Izquierdo]

Hello,

I’ve noticed that this package (along with python-dsv-sdk) attempts to share a common namespace delinea by directly including and modifying the delinea/__init__.py and delinea/secrets/__init__.py modules in both distributions
While this might work in some scenarios, it breaks compatibility with PEP 420 – Implicit Namespace Packages and introduces several significant issues:

• Namespace conflict and file clobbering:
  Since both packages provide the same files, installing them side-by-side leads to one overriding the other. This results in unpredictable behavior depending on the installation order and package version. Poetry performs by default parallel installation of packages and it ends up in corrupted files. This is also problematic for reproducibility and debugging.

• Broken namespace packaging semantics:
  PEP 420 specifically requires namespace packages to omit the init.py in the shared namespace directories. Including it turns the namespace into a standard package, making it impossible to safely merge modules across distributions.

• Version management conflicts:
  Embedding the package version inside delinea/__init__.py leads to ambiguous version resolution when both packages are installed.

[webknjaz]

FTR, here's the current technique for maintaining native/implicit namespace packages: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages. In the past (pre Python 3.3), it was common to have an __init__.py with a bunch of boilerplate in the legacy namespace packages. But this project doesn't seem to even have that.
The only usable path forward is following that guide. Though, the migration path will probably hit conflicts during the initial upgrade (when two pip installed projects claim the same file paths and end up being updated, one of them will delete the colliding files earlier than the other).