A Python entry point is a way for an installed package to advertise a component, such as a plugin, that another application can find and load by group and name. Data tools use them heavily. The consequence is simple: installing a package into the same environment can add code that the tool will import later.
What the specification says
The Python Packaging User Guide defines entry points as a mechanism for an installed distribution to advertise components it provides so other code can find and use them. Applications can load plugins this way, and the page gives the example of Pygments using lexers and styles from separately installed packages.
Each entry point has three required properties: a group, a name, and an object reference of the form module or module:object.attr. A consuming application resolves the reference by importing the module and then reading each attribute. Entries live in entry_points.txt inside the package's dist-info directory, using INI syntax:
[pytest11]
nbval = nbval.plugin
The consumer defines the group and decides how to handle two packages that use the same name.
What this means for a data environment
Notebook servers, test runners, workflow schedulers and database tools all use plugin groups. If a package declares an entry point in a group your tool reads, the tool may import it the next time it starts, without anyone adding a line to a config file.
That is convenient, and it is also why the contents of an environment matter. The specification has no security section on this subject, so the protection is up to you:
- Treat every package in a tool's environment as code the tool might run.
- Keep production environments separate from experimentation environments.
- Install from a controlled index and pin versions.
- Review new packages that arrive as transitive dependencies, not only the ones you chose.
How to see what an environment advertises
You can list entry points from Python using the standard library:
from importlib.metadata import entry_points
for ep in entry_points(group="console_scripts"):
print(ep.name, ep.value)
Change the group name to the one your tool reads. Run it in the environment where the tool runs, not on your laptop, and compare the output to the packages you expected.
Two related details
| Detail | Why it matters |
|---|---|
| Names are case sensitive | Names that differ only in case can behave unpredictably across installers, so avoid them |
| Console scripts become shell commands | Installers create a wrapper for each one, so a new package can add a runnable command to the environment |
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation produce an inventory of the packages in a project, which is the starting point for reviewing what plugin groups could load. You can run a free scan to see yours.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how transitive packages appear in the inventory next to the ones you chose.
Quick check
Does an entry point run code when a package is installed?
The specification describes it as metadata. Code runs when a consuming application loads the referenced object, which can be at the tool's next start.
Can I stop a tool from loading plugins?
That depends on the tool. Check its documentation, and keep the environment limited to packages you want it to load.
Sources
Last reviewed: 19 October 2026.
