Can I generate requirements for just one Python entry point?

Take a look at pigar. It can inspect imports and suggest the packages a project needs, so it may be a useful starting point for this kind of bootstrap task. Treat the result as a draft, though. Import names and installable package names do not always match, and static analysis can miss dependencies loaded dynamically.

If you want to build this yourself, a recursive AST walk is a reasonable first version. Start at the chosen entry point, follow imports into your own modules, and collect third-party imports along the way. You will need a mapping from import names to distribution names, and a way to distinguish local modules from installed packages.

The tricky part is that source code cannot reveal every runtime dependency. Conditional imports, plugins, reflection, and optional features can all change what gets loaded. I would label the output as inferred requirements, not a guaranteed complete environment.

If you are open to changing the format, uv lets you declare dependencies for an individual script in that script's metadata. That is useful when each entry point is a standalone script, but it is dependency declaration rather than automatic inference.

For a larger project, separate dependency groups in a pyproject.toml can also keep the dependencies for different parts of the project organized. You would still choose or verify the packages those groups contain.

For deployment, I would lean toward maintaining each environment's dependencies explicitly. A small amount of manual upkeep is often less confusing than a generated file that silently misses a conditional import or includes unrelated packages.

If several containers share some dependencies, keep a shared base and add a smaller set for each service. That makes the overlap visible without pretending the entry point alone tells the whole story.

pip freeze records what is installed in the current environment, not what one entry point uses. It can be handy after you have made a clean environment for that service, but freezing a general development environment is likely to include unrelated packages.

A practical workflow is to infer or write a short initial list, test the entry point in a fresh environment, then record the resolved environment only if you need a pinned deployment file.