https://bugzilla.redhat.com/show_bug.cgi?id=2318408 --- Comment #12 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Benson Muite from comment #11) > The split between the files is not clear, For the other two > packages, the main reason seems to be to provide a command > line interface, so the slim package contains all the working > code. The full package adds syntactic sugar that may/may not > get in the way of the user. The -slim thing, and particularly the way it is implemented, is decidedly idiosyncratic to the primary developer of these three packages, but it’s not something we can really opt out of downstream. We need dependencies on python3dist(sqlmodel), python3dist(sqlmodel-slim), or a future python3dist(sqlmodel-slim[standard]) to each be satisfiable, non-conflicting, and bring in the correct set of dependencies. Right now, python3-sqlmodel and python3-sqlmodel-slim have the same external dependencies, (python3.13dist(pydantic) < 3~~ with python3.13dist(pydantic) >= 1.10.13) (python3.13dist(sqlalchemy) < 2.1~~ with python3.13dist(sqlalchemy) >= 2.0.14) but in https://github.com/fastapi/sqlmodel/pull/916 upstream writes, “In the future SQLModel will include the standard default recommended packages, and sqlmodel-slim will come without those recommended standard packages and with a group of optional dependencies sqlmodel-slim[standard], equivalent to sqlmodel, for those that want to opt out of those packages.” You can see this with python3-typer and python3-typer-slim: $ rpm -q --requires -p results_python-typer/0.13.1/1.fc41/python3-typer-slim-0.13.1-1.fc41.noarch.rpm | grep -v rpmlib python(abi) = 3.13 python3.13dist(click) >= 8 python3.13dist(typing-extensions) >= 3.7.4.3 $ rpm -q --requires -p results_python-typer/0.13.1/1.fc41/python3-typer-slim+standard-0.13.1-1.fc41.noarch.rpm | grep -v rpmlib python(abi) = 3.13 python3-typer-slim = 0.13.1-1.fc41 python3.13dist(rich) >= 10.11 python3.13dist(shellingham) >= 1.3 $ rpm -q --requires -p results_python-typer/0.13.1/1.fc41/python3-typer-0.13.1-1.fc41.noarch.rpm | grep -v rpmlib python(abi) = 3.13 python3-typer-cli = 0.13.1-1.fc41 python3-typer-slim = 0.13.1-1.fc41 python3.13dist(click) >= 8 python3.13dist(rich) >= 10.11 python3.13dist(shellingham) >= 1.3 python3.13dist(typing-extensions) >= 3.7.4.3 The PyPI wheels for sqlmodel and sqlmodel-slim contain the same code as each other but have potentially different dependencies, with sqlmodel’s being a superset of sqlmodel-slim‘s. This is true of typer and typer-slim, and of fastapi and fastapi-slim: both wheels ship the same code. In Fedora, we could have python3-sqlmodel and python3-sqlmodel-slim co-own %{python3_sitelib}/sqlmodel and all of its contents, but since python3-sqlmodel is supposed to have all the dependencies python3-sqlmodel-slim does (and possibly more), using a dependency is just as correct, has no real disadvantages, and has fewer caveats around differing versions and file conflicts. I agree that this is all a very weird way of handling optional dependencies, and it’s somewhat confusing, but it is a very intentional upstream design decision, and the naming and arrangement of the subpackages is just a direct reflection of what upstream publishes. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2318408 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202318408%23c12 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
