What is the relation of the Python projects typer-slim, typer and the package typer?

[FCamborda]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the Typer documentation, with the integrated search.
• I already searched in Google "How to X in Typer" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to Typer but to Click.

Commit to Help

• I commit to help with one of those options 👆

Example Code

fawltydeps --check --detailed <project using typer>

Description

Somewhat related question: #784

• Up until PR 780, the GitHub repository repository included a deliverable Python project typer in it.
• The project included and still includes a Python package called typer. This is always inferred by the directory name including a __init__.py, but I guess that PDM lists this also explicitly: https://github.com/tiangolo/typer/blob/master/pyproject.toml#L57
• PR 780 changed the packaging and seems to compatibility with tools that check for unused/undeclared import statements.
  Bear in mind that FawltyDeps is not a simple parser for import-statements, but actually tries different resolution mechanisms and is unable to map import typer with the declared dependency typer. Declaring typer-slim as a dependency fixes the problem, but this is not shown in any documentation.
• It is not clear which one should be depended on under which circumstances. My understanding is that now typer-slim is the dependency to be declared for projects using typer to generate CLIs programmatically. Was this intended? This is not mentioned in the documentation.

fawltydeps --check --detailed

These imports appear to be undeclared dependencies:
- 'typer' imported at:
    src/<name>/__main__.py:6
    src/<name>/cli.py:8

These dependencies appear to be unused (i.e. not imported):
- 'typer' declared in:
    pyproject.toml

We can fix this by adding an identity mapping:

[tool.fawltydeps.custom_mapping]
typer = ["typer"]

But this feels artificial to me (and is also supposed to be a last resort). What has changed so that typer is not recognized as typer anymore?

I tried to understand the packaging setup, but unfortunately I'm not familiar with your tools. Maybe this line is not really working?
https://github.com/tiangolo/typer/blob/master/typer_package/pyproject.toml#L48

Operating System

Linux, Windows

Operating System Details

No response

Typer Version

0.12

Python Version

3.10

Additional Context

No response

[odrling]

From what I understand of the packaging, the typer-slim package contains the typer module, typer-cli provides the typer wrapper script, and then typer is now a "metapackage" to install typer-slim, typer-cli, rich, and shellingham.
So indeed the typer package doesn't directly provide the typer module as it used to, which is probably why fawltydeps reports errors.

I'm personally also confused by the new packaging, typer-slim doesn't feel that much slimmer when it actually is the only package that has any code. It seems "slim" is more related to it not installing rich and shellingham, I'm not convinced typer-slim not including the typer wrapper script makes much sense (it's just a wrapper script calling a function in the typer module).

I think the intended effect is to have the typer package provide all the features available in Typer by default, which is pretty convenient, I'll admit. Perhaps the "correct" way to do that currently (as in what can be done today in python packaging without leading to other issues like #784) would have been to build two packages that provide the typer module directly. I'd otherwise kind of want to have a way to declare optional dependencies in a python package that could be installed by default and can be excluded explicitly by the user. (or if there is already a way to do that I think that's what should be done with Typer)

[tiangolo]

I just updated the release notes to include more info about it: https://typer.tiangolo.com/release-notes/#0121

Copying from there:

---

In version 0.12.0, the typer package depends on typer-slim[standard] which includes the default dependencies (instead of typer[all]) and typer-cli (that provides the typer command).

If you don't want the extra optional dependencies (rich and shellingham), you can install typer-slim instead.

You can also install typer-slim[standard], which includes the default optional dependencies, but not the typer command.

In version 0.12.0 the typer-cli package only provides the typer command, but the code is still in the main code, so even without installing typer-cli, it can be called with python -m typer.

This approach of having typer depend on typer-slim[standard] instead of including the whole code and dependencies itself caused an issue when upgrading from typer <0.12.0 to typer >=0.12.0, see issue #790. This is fixed in version 0.12.1.

[superdosh]

I'm running into an issue where I have two dependencies, one of which depends on typer<0.20 and one on typer-slim==*. They end up resolving to different versions, and clobbering each other during install. In the reply here, if typer depends on typer-slim, I don't think this should be possible? But perhaps that's no longer true as I know this is almost 2 years old now.

We're resolving the issue by pinning both typer and typer-slim in our project, which is not ideal. Is there maybe a better way to deal with this? Happy to create a separate issue/question if this is too stale now.