Dependencies can absolutely be a problem. Let’s say you have a Python program that relies on an older version of a package due to a breaking change. With Arch those packages are installed in a per-Python interpreter global namespace. So if two applications have conflicting version requirements for a package, you’re kind of screwed. Yes, there are ways around the issue, but it’s not customarily used in Arch.
This is just not a problem with Flatpak. The dependencies can be installed directly with no fears about causing a conflict. Even if the Flatpak itself uses a runtime, that runtime allows the Flatpak to add its Python dependencies as a simple layer on top. This happens independently of any other Flatpaks.
Dependencies can absolutely be a problem. Let’s say you have a Python program that relies on an older version of a package due to a breaking change. With Arch those packages are installed in a per-Python interpreter global namespace. So if two applications have conflicting version requirements for a package, you’re kind of screwed. Yes, there are ways around the issue, but it’s not customarily used in Arch.
This is just not a problem with Flatpak. The dependencies can be installed directly with no fears about causing a conflict. Even if the Flatpak itself uses a runtime, that runtime allows the Flatpak to add its Python dependencies as a simple layer on top. This happens independently of any other Flatpaks.