Introduction

ImportError cannot import name 'main' on Python 3.6 in RHEL6 is usually caused by package layout, naming conflicts, or environment mismatch rather than a Python bug. Older enterprise Linux systems add complexity because multiple Python runtimes and legacy path settings often coexist. A systematic import-path and package-structure check usually resolves the issue quickly.

Reproduce and Isolate the Failing Import

Start with a minimal failing command.

python3.6 -c "from mypackage import main"

Then inspect what module Python is loading:

python3.6 -c "import mypackage, sys; print(mypackage.__file__); print(sys.path)"

If the wrong file is loaded, path ordering or naming collision is likely the problem.

Verify Package Structure and __init__.py

Expected structure should be explicit.

1project/
2  mypackage/
3    __init__.py
4    main.py

If you want from mypackage import main to work, either:

• keep main.py module and import it explicitly, or
• re-export symbol in __init__.py.

Example __init__.py:

from . import main

Or for function re-export:

from .main import main

Ambiguous layouts with missing __init__.py or mixed namespace behavior can trigger import failures.

Avoid Name Collisions

A frequent cause is local files shadowing package names.

Examples of problematic files:

• main.py in current working directory,
• mypackage.py file conflicting with mypackage directory,
• stale bytecode in old locations.

Quick checks:

find . -maxdepth 2 -name "main.py" -o -name "mypackage.py"
find . -name "__pycache__" -type d -print

Clear stale cache when debugging import changes.

Check Virtual Environment and Interpreter Consistency

On RHEL6, it is common to run scripts with one interpreter while installing packages into another.

which python3.6
python3.6 -m pip --version
python3.6 -c "import sys; print(sys.executable)"

Always install packages with the same executable used for runtime:

python3.6 -m pip install -e .

This avoids path drift across system Python and virtualenv installations. It also improves reproducibility across environments.

Use Absolute and Explicit Imports

Inside packages, prefer explicit relative or absolute imports.

# in mypackage/runner.py
from .main import main

or

from mypackage.main import main

Avoid relying on implicit import side effects in package init files unless necessary.

Debug Import Resolution Verbosely

Use verbose import tracing to see lookup behavior.

python3.6 -v -c "from mypackage import main"

This prints module search paths and loaded files, which often reveals shadowed modules immediately.

Compare Editable and Wheel Installation Modes

Editable installs can hide packaging issues because imports use your local source tree directly. Reproduce production behavior with wheel installation when debugging deployment-only failures.

python3.6 -m pip uninstall -y mypackage
python3.6 -m pip install dist/mypackage-*.whl
python3.6 -c "from mypackage import main; print(main)"

Testing both installation modes helps detect missing package data or incorrect setup configuration. It also confirms whether failures are path-related or packaging-related. This distinction speeds root-cause analysis on legacy Linux hosts.

Common Pitfalls

A common mistake is assuming from package import main will automatically find a function named main. Python first resolves module attributes and package exports based on package structure.

Another issue is mixed interpreter usage on older Linux systems. If pip installs into a different runtime, imports fail even though package appears installed.

Developers also keep project root naming that collides with dependency package names, causing unexpected module resolution and circular import symptoms.

Summary

• Confirm exact package layout and export behavior in __init__.py.
• Check for module name collisions in project directories.
• Use the same Python executable for install and runtime.
• Prefer explicit imports and avoid ambiguous package side effects.
• Use verbose import tracing to identify path and resolution problems quickly.