CODEWITHSUNDEEP
pythonprogram-entry-point
javidcf
javidcf

Reputation: 59711

Detect whether package is being run as a program within __init__.py

I have a Python package with an __init__.py that imports some things to be exposed as the package API.

# __init__.py

from .mymodule import MyClass
# ...

I also want to be able to use the package as a command-line application, as in python -m mypackage, so I have a __main__.py file for that purpose:

# __main__.py

if __name__ == '__main__':
    from .main import main
    main()

So far so good. The problem is that, when the package is run as a program like this, I want to be able to do some stuff before importing any of the submodules - namely changing some environment variables before some third-party dependencies are loaded.

I do not know how to do this, at least not in a reasonable way. Ideally, I would like to do something like:

# __init__.py

def thePackageIsRunningAsAnApplication():
    # ???

def prepareEnvironment():
    # ...

if thePackageIsRunningAsAnApplication():
    prepareEnvironment()

from .mymodule import MyClass
# ...

The problem is I don't think thePackageIsRunningAsAnApplication() can be implemented. The usual __name__ == '__main__' does not work here, because the main module being run is __main__.py, not __init__.py. In fact, I would prefer to define and run prepareEnvironment within __main__.py, but I don't know how to get that to run before the inner modules are loaded by __init__.py.

I might (not sure, actually) work around it by lazily loading dependencies on my module, or somehow delaying the internal module loading or something, but I would prefer to avoid doing something like that just for this.

EDIT: Thinking more about it, lazy loading probably would not work either. In the example, MyClass is, well, a class, not a submodule, so I cannot lazily load it. Moreover, MyClass happens to inherit from a class from that third-party dependency I was mentioning, so I cannot even define it without loading it.

Upvotes: 5

Views: 453

Answers (2)

Blckknght
Blckknght

Reputation: 104722

It might make sense to add a separate entry point for running your code as a script, rather than using __main__.py, which as you've noticed, can only be run after the package's __init__.py is fully loaded.

A simple script like run_mypackage.py located at the top level could contain the environment variable tweaking code, and then could import and run the package afterwards.

def prepare_environment():
    ...

if __name__ == "__main__":
    prepare_environment()            # adjust the environment firstt

    from mypackage.main import main  # then load the package afterwards
    main()

Upvotes: 1

4lexKidd
4lexKidd

Reputation: 158

Not 100% sure what you want to do pre-import wise.

Afaik there is no preprocessor step before imports. In other languages than python there usually are compiler flags which can be read before imports are done but i don't know if python has those to.

I possible solution to do stuff pre-import wise could be to have a seperate package that is imported before your other submodules (ofcourse you would need some kind of switch to not have it run when you call/use the package the usual external way). At import of the package the whole package is run (if there is no name == 'main' part) which can be used to do stuff before the other modules are importet. But if you mean solving some environment issues when your programm is called on the different way i think there is no way for having multi-importpath resolution without ambiguity. There are relative import paths if your package is locally saved but i don't think they can be used that way. Would be some interesting experiment though.

Upvotes: 0

Related Questions