Add support for namespace-packages without __init__.py (PEP420)
See original GitHub issueIn Python 3 modules don’t require an __init__.py
anymore, they are referred to as namespace packages then (see PEP 420 for details). It seems that those are not supported by import-linter at the moment, I’m getting Could not find package.initless.module when scanning …. This may be due to a missing __init__.py file in the parent package
warnings and Module 'package.initless' does not exist.
errors. In my case the structure is roughly:
package
__init__.py
initless
module.py
It would be great if this could be supported.
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (4 by maintainers)
Top Results From Across the Web
Packaging namespace packages
Use native namespace packages. This type of namespace package is defined in PEP 420 and is available in Python 3.3 and later. This...
Read more >Support for namespace packages (PEP 420) #19 - GitHub
PEP 420 introduced implicit namespace packages, which are packages without __init__.py . Those packages, and the modules under them, don't seem ...
Read more >PEP 420 is accepted... and __init__.py won't be required ...
Directories with __init__.py will act the same as they did before, with no automatic combining of different directories, and disabling feature #2 for...
Read more >python - How to load implicit namespace package by adding ...
native namespace packages; pkgutil-style namespace packages; pkg_resources-style namespace packages. The former two are not zip-safe, and that's ...
Read more >How to create python namespace packages in Python 3?
Use packages for native namespaces. The PEP 420 specification for this kind of namespace package states that Python 3.3 and later support it....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I’m pleased to say there is now a PR in place which offers support for namespace packages: https://github.com/seddonym/import-linter/pull/127
@tozka This should now meet your needs. @jstriebel, I have a feeling this won’t exactly fulfil your needs I’m afraid but you might want to take a look just in case.
Comments and testing welcome.
We also use namespace packages. We have separate distribution packages using common root package.
Another benefit: Namespace packages make it easier to develop when you have multiple modules with the asme common prefix e.g I have a project “cool” - with package “companyname.cool” and project “hot” that depends on cool.
While developing cold we would use pip install -e . to install it in editable form and thus companyname.hot would be from local folder while companyname.cool would be from site-packages of python. Without namespace packages only one would be found.
import-linter looked really promising for us but we need namespace packages so we cannot use it.