Revert "Do not append namespace packages to sys.path (#6405)"

[Pierre-Sassoulas]

Type of Changes

	Type
✓	🐛 Bug fix
✓	✨ New feature
✓	🔨 Refactoring
✓	📜 Docs

Description

This reverts commit 603be84. See #6538 (comment)

Should we reopen #5226, and #2648 ?

[coveralls]

Pull Request Test Coverage Report for Build 2290019500

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.004%) to 95.341%

---

Totals
Change from base Build 2289989458:	-0.004%
Covered Lines:	16003
Relevant Lines:	16785

---

💛 - Coveralls

[jacobtylerwalls]

I hope to write a regression test case. Maybe we should merge that before reverting this. I think in trying to distill a minimal example I simplified it too much 😓

[jacobtylerwalls]

I think in trying to distill a minimal example I simplified it too much 😓

Turned out it was just that generic names like "test", "a", and "b" were ambiguous on my system. Using unique names helps to reproduce. I'll try to get a PR going with a test.

[jacobtylerwalls]

Er.... it was actually that the parent of the namespace directory needed to be on sys.path! See #6553 for the test.

[jacobtylerwalls]

Should we reopen #5226, and #2648 ?

👍🏻 And add them to 2.15

[Pierre-Sassoulas]

@DanielNoord should we merge #5235 then ? Permitting user to disable sys.path patching when it make sense could be a temporary solution ?

[DanielNoord]

@DanielNoord should we merge #5235 then ? Permitting user to disable sys.path patching when it make sense could be a temporary solution ?

Like I said previously, I don't think so until we have fully investigated the issue. We would only end up having to support an option that does not mimic actual Python behaviour. Until we are sure we can't fix our handling of namespace packages we shouldn't do so I think.