Module name collision when different apps share module names

I’ve encountered a critical issue with Frappe’s module mapping system and wanted to bring it to the community’s attention. I’ve also opened a GitHub issue for tracking.

GitHub Issue: Module name collision on different apps installed in different sites · Issue #34895 · frappe/frappe · GitHub

The Problem

When two independent apps declare a module with the same name in their modules.txt, Frappe’s setup_module_map() function overwrites the module→app mapping, causing the last app in apps.txt to “win.” This leads to ImportError when loading DocTypes that belong to the first app.

Quick Example

If ERPNext has a “Stock” module and a custom app also declares “Stock”:

  • Database says Stock belongs to ERPNext
  • In-memory cache says Stock belongs to custom app
  • Result: Frappe tries to load ERPNext DocTypes from the custom app → crash

Reproduction

  1. Create a custom app with a module named “Stock” in modules.txt
  2. Install ERPNext first, then the custom app
  3. ERPNext installation fails with ImportError: No module named 'customapp.stock.doctype...'

Root Cause

In frappe/__init__.py (lines 1678-1688), the mapping simply overwrites without conflict resolution:

local.module_app[module] = app  # Last app wins!

A warning is issued but doesn’t prevent the problem.

Discussion

Has anyone else encountered this? Any insights appreciated!

Unfortunately this is expected behavior. A decision was made to set module as global (they must be unique).

In my opinion “module” should be unique for each site (like doctype) but not at bench level that can manage multiple sites or apps.
For me it’s a design or a bug fault that should be solved

same issue here

1 Like

It certainly isn’t a bug (it’s a feature). Per-site would be impractical, but if the devs used some sort of dot-notation to include the parent directory/App or evaluate app+module it could reduce collisions.

Once you know they have to be unique, it’s not a deal breaker for most people.