main entry point python

Python Entry Points Explained

In this post I’m going to explain about entry points in Python. Most people know entry points as the little snippet that you put in your setup.py file to make your package available as a script on the command line, but they can be used for so much more. I’m going to show you how to use entry points as a modular plug-in architecture. This is super useful if you want to let other people write Python packages that interact or add abilities to your existing Python package at runtime.

Congratulations! You have just been appointed CEO of “Snek Semiconductors and Software, Incorporated”. Your first job as CEO is, obviously, to instruct your R&D department to develop a snek prototype ASAP. And so, they get to work, writing snek.py :

Their prototype was displayed at the company demo day, and it worked!

SaaS - Snek as a Service

Unfortunately, customers don’t know about Python (except for the snek). They want easy access to snek from any path in the shell without needing to worry about this Python thing, or finding snek.py . So the gals over at R&D worked all night and came up with a way to package snek in a way that automagically creates a console script when it’s installed. When you create a distribution for a Python package, you need to have a setup.py file that contains the package’s name, dependencies, etc. It can also be used to register entry points and it looks like this:

console_scripts , they say, is a special type of entry point. setuptools reads its content as "<console script name> = <python object path>" and creates an appropriate script when your package is installed. Right now, they are installing it from source:

At the keynote talk in the highly-acclaimed SnekCon conference (tickets sold out six months in advance) you take the stage and present it for the world to marvel at:

Snek for Everyone

Everyone loves snek. “Snek Semiconductors and Software, Incorporated” has an IPO and is valued at over 60 billion dollars. Hipsters are demanding a fancier version of snek. And your R&D team delivers:

They’ve added a fancy snek. Now the hipsters are happy.

Snek International Community

Millions all over the world are using snek. Even after acquihiring Google, “Snek Semiconductors and Software, Incorporated” just can’t keep up with the increasing demand for more and more versions of snek! Professional customers are demanding a customizable version of snek! They want to create their own snek on top of the snek infrastructure. R&D better get to work.

They have added the infrastructure for customizable sneks. Whenever snek is run, it looks for other sneks that registered using an entry point called snek_types . Each snek is a string registered under a type name. That name can be used with the console script to dynamically print a custom snek.

In particular, the magic happens in get_sneks . The call to pkg_resources.iter_entry_points('snek_types') iterates over all the entry points that were registered under the name "snek_types" . So, external packages can define an entry point called "snek_types" in their setup.py , and snek will dynamically load it at runtime.

The guys over at “Snek Pro Solutions and Consultation Services” have been notified about the "snek_types" entry point and have started working on a far better version of snek than you could dream of. A cute snek. They have created a simple cute_snek.py with very little code:

They are packaging cute_snek , but they also need to let snek know how to find the cute snek.

They registered the cute_snek variable in the cute_snek module under the name cute . Now, they install both snek and cute_snek

Now, running snek , they can produce a cute snek, which is dynamically loaded from the cute_snek package:

Snek Infrastructure Overhaul

Your VP R&D has a request. He want to stop development for a while, while his engineers clean up the snek infrastructure for a better looking code base. You are too distracted by the public allegations that you embezzled sneks while doing insider-trading in the snek market, so you allow it.

The engineers in R&D have come to the conclusion that if some sneks can be dynamically loaded, all sneks can be dynamically loaded! Even built-in sneks! They removed special treatment of existing sneks:

And, instead, registered them like any other snek:

Now, you need to re-install snek for the new entry points to take:

This is indeed one small snek for snek, and one giant snek for snek kind (also, you know how to use Python entry points).

Similar Posts

• Python Attribute Access and the Descriptor Protocol
• File Parts: Cheat Sheet
• Python Idioms: Multiline Strings
• Cleaning Up in a Python Generator Can Be Dangerous
• Write Explicit Tests
• PyCharm Settings Repository

DEV Community

Posted on Apr 9, 2020

Entry points in Python

What's an entry point.

The most relevant bit of the description in Wikipedia is:

In computer programming, an entry point is where the first instructions of a program are executed, and where the program has access to command line arguments. To start a program's execution, the loader or operating system passes control to its entry point.

What we're going to cover in this blog post is the various methods that you can define entry points in your Python programs. Some with obvious downsides as we'll discover.

Keeping it simple: Python scripts

The simplest thing that you can do is treat your Python file as a self-contained script. Here's the old "Hello world!" example:

Running this file directly gives us an implicit entry point: Just by running the script we get right into execution:

Easy, right? So what's the problem here?

The downside

What if your project became complex enough to warrant multiple modules? What if you want to import and say hello from another module? With the above, this is what would happen:

As you can see in the above, the problem with the Python script approach is that it's overly simple and functionality is executed at import time , which is typically not what you're after. Not only is it functionally not what you're going to be after, but writing unit test for it will be difficult if not impossible, especially if there is any state change through side effects.

So how can we solve this? Read on!

Leveling up: What's my name?

So now we know that sticking all of our functionality in a Python script isn't the best approach if we want to reuse or write unit tests. So then, what's the next best thing? Using the if name == ' main ' pattern.

From the Python docs :

'__main__' is the name of the scope in which top-level code executes. A module’s name is set equal to '__main__' when read from standard input, a script, or from an interactive prompt. A module can discover whether or not it is running in the main scope by checking its own name , which allows a common idiom for conditionally executing code in a module when it is run as a script or with python -m but not when it is imported.

If we adopt this new learning to hello_world.py , it would then look like this:

So, now running it from the command line will still yield the same result:

The major difference though, is that now our import time problem has been solved. Rather than seeing "Hello world!" at module import, we have to explicitly call say_hi() :

This will now also allow us to write and run unit tests against the hello_world module without having to worry about import time side effects.

The observant reader will notice that the Python docs also refers to running Python modules directly with python -m . This would allow you to run hello_world without making it executable and adding the shebang at the beginning of the file:

Another example of this is the standard module's json.tool :

"This is awesome! All my problems are solved!" says you. "Nay" says I. "Not quite yet".

Now we have entry points in Python files that we can unit test against. Great. But what are we to do if our project really increases in size? How do we find which modules have entry points defined and which ones don't? There must be a better option than:

Indeed there is, dear reader. Indeed there is.

Come together: Script organization

Now that we know about the if __name__ == '__main__' pattern, how do we avoid the confusing aspect of figuring out which files are actually executable? Well, this one has two facets, both of which are fine on their own but shine when used together:

Add a scripts directory to your project

By adding a scripts directory, you can lump all of your entry points into a single directory, making it ridiculously simple for anyone looking at your project to find all of the various entry points for your project. After doing this with hello_world.py , this is what our directory structure looks like:

For a new user or developer just coming into the project, this makes it tremendously simple to figure out what entry points are available in your project.

How can we enhance this experience you ask? That part comes with the introduction of setuptools . In the above, you'll notice a setup.py file. It's within there that we want to define scripts to be installed when the user installs your package:

For ease of use, I've also dropped the extension in hello_world .

Now when a user installs the package, here's what they'll see:

The important thing to note in the above is Installing hello_world script to /path/to/.venv/bin . This means that users now don't have to fiddle with running ./scripts/hello_world or python -m hello_world , they can simply run the script directly:

"What is this magic?!" you ask?

For each entry in the scripts entry, a file will be created in your environment's Python bin dir. The resulting file looks like this:

So the executable script written to the bin directory effectively acts as a redirect to your source file, executing it.

The combination of the approaches to this point should be enough to satisfy even complex projects. However, if you want to know a completely different option (and my personal favorite), read on!

And now for something completely different: entry_points

The combination of console_scripts and entry_points in a project's setup.py can help us achieve the same results as the previous sections, but without the need for the if __name__ == '__main__' pattern. This is achieved by specifying a callable entry points in the setuptools config:

Noting that we're back to the original directory structure:

Our setup.py file might now look something like this:

The observant reader will notice that as we're configuring the entry point to be a callable, this is now something that can easily be unit tested directly.

The magic sauce that allows us to run the script directly looks a little different than the treatment it gets from scripts :

Definitely has some functional differences, but at a high level the results are effectively the same:

Gettin' jiggy with it: Single entry point

"So I have a couple ways to define entry points" you say. "But what if I want to have multiple entry points? Does that mean that I need to have multiple executables for my single application?"

Great question! And of course, the answer is "no", but how you solve that problem is entirely up to you.

An approach that I've used in the past is to define a single entry point and to create a commands directory and a module for each sub-command I want available.

The project structure would now look like this:

The app.py module is simplistic, but captures one potential approach (how it does what it does is an exercise left to the reader):

And the actual command ( say_hi.py ) looks like this:

If you have multiple commands, which I would hope you are if you're using this approach, then you could either rely on duck typing as I am above, or define an abstract base class and ensure the command being imported in app.py is an instance of that interface. The latter is likely the better of the approaches if multiple people are contributing to the code base.

Then running it after installing becomes:

Or... Y'know... You could use a sane library like click to do this instead of rebuilding the wheel.

You're just a wee bit more dangerous now!

Hopefully you've learned some new tips and tricks here and your next project won't make your new hire want to pull their hair out trying to figure out how the entry points in your project work.

Top comments (2)

Templates let you quickly answer FAQs or store snippets for re-use.

• Education Gebze Technical University
• Work Undergraduate Research Assistant at TUBITAK
• Joined Feb 3, 2022

hey man, thanks for sharing this with us! I dont know maybe its something basic, we should have known, but under the title of Script organization, """ scripts=['scripts/hello_world'] """ part didnt worked with me. The file couldnt be found. So i add .py extension, then it was fine. Also i needed to write """ import setuptools """ as well. It took some time for me to figure it out. So just wanted to inform the others. Regards.

• Joined Nov 2, 2021

Great write up! It would be helpful to show how to do this with setup.cfg and pyproject.toml

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

Cómo crear un servidor web en tu proyecto vanilla javascript

David Ruiz - Nov 28

Validate email addresses using regular expressions

Nw3965 - Nov 28

100 Bucket List Ideas for Programmers

Syki - Dec 4

Python - Implement Breadth-First Search (BFS) for Graph and Tree Traversal

Keyur Ramoliya - Nov 28

Once suspended, demianbrecht will not be able to comment or publish posts until their suspension is removed.

Once unsuspended, demianbrecht will be able to comment and publish posts again.

Once unpublished, all posts by demianbrecht will become hidden and only accessible to themselves.

If demianbrecht is not suspended, they can still re-publish their posts from their dashboard.

Once unpublished, this post will become invisible to the public and only accessible to Demian Brecht.

They can still re-publish the post if they are not suspended.

Thanks for keeping DEV Community safe. Here is what you can do to flag demianbrecht:

demianbrecht consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy.

Unflagging demianbrecht will restore default visibility to their posts.

We're a place where coders share, stay up-to-date and grow their careers.

Python - Main (Entry Point)

Language - (Main|Application Entry point) In Python.

Articles Related

• Python - Script
• Python - Builtin Function

Specification

• https://packaging.python.org/specifications/entry-points/
• In the Python Package - init .py . Example: https://github.com/pypa/sampleproject/blob/master/sample/__init__.py

executable scripts

To provide executable scripts, use entry points in preference to the “scripts” keyword. Entry points provide cross-platform support and allow pip to create the appropriate form of executable for the target platform.

For example, the following would provide a command called sample which executes the function main from this package when invoked:

• in Python - setup.py , See entry_points

When you want to make a script executable, the if statement makes that The code is not executed when the script is imported as a module.

where __name__ has the value:

• foo when the module is imported
• or __main__ when executed from Python.

Documentation / Reference

• Python »
• 3.12.0 Documentation »
• The Python Standard Library »
• Python Runtime Services »
• __main__ — Top-level code environment
• Theme Auto Light Dark |

__main__ — Top-level code environment ¶

In Python, the special name __main__ is used for two important constructs:

the name of the top-level environment of the program, which can be checked using the __name__ == '__main__' expression; and

the __main__.py file in Python packages.

Both of these mechanisms are related to Python modules; how users interact with them and how they interact with each other. They are explained in detail below. If you’re new to Python modules, see the tutorial section Modules for an introduction.

__name__ == '__main__' ¶

When a Python module or package is imported, __name__ is set to the module’s name. Usually, this is the name of the Python file itself without the .py extension:

If the file is part of a package, __name__ will also include the parent package’s path:

However, if the module is executed in the top-level code environment, its __name__ is set to the string '__main__' .

What is the “top-level code environment”? ¶

__main__ is the name of the environment where top-level code is run. “Top-level code” is the first user-specified Python module that starts running. It’s “top-level” because it imports all other modules that the program needs. Sometimes “top-level code” is called an entry point to the application.

The top-level code environment can be:

the scope of an interactive prompt:

the Python module passed to the Python interpreter as a file argument:

the Python module or package passed to the Python interpreter with the -m argument:

Python code read by the Python interpreter from standard input:

Python code passed to the Python interpreter with the -c argument:

In each of these situations, the top-level module’s __name__ is set to '__main__' .

As a result, a module can discover whether or not it is running in the top-level environment by checking its own __name__ , which allows a common idiom for conditionally executing code when the module is not initialized from an import statement:

For a more detailed look at how __name__ is set in all situations, see the tutorial section Modules .

Idiomatic Usage ¶

Some modules contain code that is intended for script use only, like parsing command-line arguments or fetching data from standard input. If a module like this was imported from a different module, for example to unit test it, the script code would unintentionally execute as well.

This is where using the if __name__ == '__main__' code block comes in handy. Code within this block won’t run unless the module is executed in the top-level environment.

Putting as few statements as possible in the block below if __name__ == '__main__' can improve code clarity and correctness. Most often, a function named main encapsulates the program’s primary behavior:

Note that if the module didn’t encapsulate code inside the main function but instead put it directly within the if __name__ == '__main__' block, the phrase variable would be global to the entire module. This is error-prone as other functions within the module could be unintentionally using the global variable instead of a local name. A main function solves this problem.

Using a main function has the added benefit of the echo function itself being isolated and importable elsewhere. When echo.py is imported, the echo and main functions will be defined, but neither of them will be called, because __name__ != '__main__' .

Packaging Considerations ¶

main functions are often used to create command-line tools by specifying them as entry points for console scripts. When this is done, pip inserts the function call into a template script, where the return value of main is passed into sys.exit() . For example:

Since the call to main is wrapped in sys.exit() , the expectation is that your function will return some value acceptable as an input to sys.exit() ; typically, an integer or None (which is implicitly returned if your function does not have a return statement).

By proactively following this convention ourselves, our module will have the same behavior when run directly (i.e. python echo.py ) as it will have if we later package it as a console script entry-point in a pip-installable package.

In particular, be careful about returning strings from your main function. sys.exit() will interpret a string argument as a failure message, so your program will have an exit code of 1 , indicating failure, and the string will be written to sys.stderr . The echo.py example from earlier exemplifies using the sys.exit(main()) convention.

Python Packaging User Guide contains a collection of tutorials and references on how to distribute and install Python packages with modern tools.

__main__.py in Python Packages ¶

If you are not familiar with Python packages, see section Packages of the tutorial. Most commonly, the __main__.py file is used to provide a command-line interface for a package. Consider the following hypothetical package, “bandclass”:

__main__.py will be executed when the package itself is invoked directly from the command line using the -m flag. For example:

This command will cause __main__.py to run. How you utilize this mechanism will depend on the nature of the package you are writing, but in this hypothetical case, it might make sense to allow the teacher to search for students:

Note that from .student import search_students is an example of a relative import. This import style can be used when referencing modules within a package. For more details, see Intra-package References in the Modules section of the tutorial.

The content of __main__.py typically isn’t fenced with an if __name__ == '__main__' block. Instead, those files are kept short and import functions to execute from other modules. Those other modules can then be easily unit-tested and are properly reusable.

If used, an if __name__ == '__main__' block will still work as expected for a __main__.py file within a package, because its __name__ attribute will include the package’s path if imported:

This won’t work for __main__.py files in the root directory of a .zip file though. Hence, for consistency, minimal __main__.py like the venv one mentioned below are preferred.

See venv for an example of a package with a minimal __main__.py in the standard library. It doesn’t contain a if __name__ == '__main__' block. You can invoke it with python -m venv [directory] .

See runpy for more details on the -m flag to the interpreter executable.

See zipapp for how to run applications packaged as .zip files. In this case Python looks for a __main__.py file in the root directory of the archive.

import __main__ ¶

Regardless of which module a Python program was started with, other modules running within that same program can import the top-level environment’s scope ( namespace ) by importing the __main__ module. This doesn’t import a __main__.py file but rather whichever module that received the special name '__main__' .

Here is an example module that consumes the __main__ namespace:

Example usage of this module could be as follows:

Now, if we started our program, the result would look like this:

The exit code of the program would be 1, indicating an error. Uncommenting the line with my_name = "Dinsdale" fixes the program and now it exits with status code 0, indicating success:

Note that importing __main__ doesn’t cause any issues with unintentionally running top-level code meant for script use which is put in the if __name__ == "__main__" block of the start module. Why does this work?

Python inserts an empty __main__ module in sys.modules at interpreter startup, and populates it by running top-level code. In our example this is the start module which runs line by line and imports namely . In turn, namely imports __main__ (which is really start ). That’s an import cycle! Fortunately, since the partially populated __main__ module is present in sys.modules , Python passes that to namely . See Special considerations for __main__ in the import system’s reference for details on how this works.

The Python REPL is another example of a “top-level environment”, so anything defined in the REPL becomes part of the __main__ scope:

Note that in this case the __main__ scope doesn’t contain a __file__ attribute as it’s interactive.

The __main__ scope is used in the implementation of pdb and rlcompleter .

Table of Contents

• What is the “top-level code environment”?
• Idiomatic Usage
• Packaging Considerations
• import __main__

Previous topic

builtins — Built-in objects

warnings — Warning control

• Report a Bug
• Show Source