__init__.py: do we still need them? about python-template HOT 7 CLOSED

Ok, Sphinx compatibility is important. I will retract my issue then, thanks for the discussion all.

from python-template.

Btw (besides the point, but related): the __init__.py in the module is currently not strictly PEP8 compliant, the metadata tags should always come before any imports: https://peps.python.org/pep-0008/#module-level-dunder-names. If we don't remove it, we should fix it.

from python-template.

+1 for deleting

from python-template.

From the documentation on packaging namespace packages:

Namespace packages allow you to split the sub-packages and modules within a single package across multiple, separate distribution packages (referred to as distributions in this document to avoid ambiguity).
...
Namespace packages can be useful for a large collection of loosely-related packages (such as a large corpus of client libraries for multiple products from a single company). However, namespace packages come with several caveats and are not appropriate in all cases

The impression I get from reading this, is that they are needlessly complex for most use cases and should probably be avoided unless you have a good reason to use them. Having the __init__.py files around also gives you a good place to write documentation for your modules.

We probably don't need metadata tags in the __init__.py file, I've never seen that used in the wild.

from python-template.

The impression I get from reading this, is that they are needlessly complex for most use cases and should probably be avoided unless you have a good reason to use them.

Do you mean namespace packages are complex? There's really not much complexity about them that I can see... Yes, they allow the more complex packaging option of splitting out optional parts of packages into separate packages, but in fact they do so in a way that makes it seem trivial. No configuration is necessary in most cases, everything is autodiscovered.

from python-template.

I mean

namespace packages come with several caveats and are not appropriate in all cases

Personally I do not have experience with using namespace packages, so I cannot tell what those caveats are, but one of those caveats that I am aware of is that standard tricks to figure out where a file is located (e.g. when you need some data that is located in the same directory as the Python module that is using it) module_name.__file__ or module_name.__path__ does not work in namespace packages and you need to use the more complicated importlib.resources standard library module. This can come as a surprise to unsuspecting users.

from python-template.

Do note that while __init__ is not required anymore for Python packaging, some tools still do depend on it.

I experienced that this week with the sphinx autoapi extension. It still doesn't fully/easily/properly support implicit namespace packages. For me the easiest fix here was to just add a __init__.py file in the right folder...

from python-template.