PEP 771: Default Extras for Python Software Packages

Packaging Standards
1

Hi everyone,

Along with @jonathandekhtiar we have written PEP 771: Default Extras for Python Software Packages which is now published as a draft!

Short summary

For anyone who hasn’t seen a previous version of this PEP, in short the aim of this PEP is to propose a way for Python packages to define one or more extras that get installed by default if no extras are explicitly specified. The two main cases this aims to solve are:

  • packages that have recommended but not required dependencies that should ideally be installed for most users while allowing advanced users to do minimal installs
  • packages that need at least one frontend/backend to be installed in order to work and for which it would be ideal for a ‘default’ to be installed for users if no other is requested explicitly

Fundamentally the goal here is to improve end user experience by avoiding having to specify extras for the most common use cases. The approach described in the PEP would allow for example cases like:

pip install package              # installs recommended dependencies
pip install package[minimal]     # installs only required dependencies
pip install package[additional]  # installs recommended and additional dependencies

I encourage you to take a look at the PEP for full details about the different motivating use cases and the different ways that the approach in the PEP can be used to solve these use cases, and for links to a full working implementation of pip and setuptools that you can try out.

Changes since the last draft

A previous draft of this PEP was discussed in this thread. We have made a number of changes based on points raised in that discussion. Here is a summary of the changes:

  • A note was added in the Specification to indicate that Metadata-Version will need to be bumped to the next minor version (originally requested by @dustin, @pf_moore and @konstin)

  • The Default-Extra field is now desribed as being ‘multiple use’ in the Specification section and it is explicitly stated that only entried already present in a Provides-Extra can be used in a Default-Extra (originally requested by @pf_moore)

  • Most of the former How to teach this section has been moved to a new Examples sub-section of the Specification section and the How to teach this section is a significant new section (originally requesetd by @pf_moore), and covers things such as:

    • supporting older versions of package installers and the various aspects related to this that package authors need to consider
    • avoiding bloating package dependencies
    • when to have extras inherit default extras
    • how to deal with the cases of incompatible and circular dependencies
    • considerations for package repository maintainers

  • The Motivation section now includes three real-world examples for each general use case (originally requested by several people including @konstin @pf_moore). In addition, the new Examples sub-section includes one concrete example in each sub-section. I’d be happy to add or replace any of the examples if anyone would like to suggest more.

  • The default-optional-dependencies key in pyproject.toml has been renamed to default-optional-dependency-keys to make it clearer it is not a list of dependencies but of keys. If anyone has a more concise suggestion, let me know! :sweat_smile:

  • @pf_moore suggested adding a Transition section, but I found while trying to write it that there is a lot of overlap with How to teach this, so I have decided to just keep the latter for now unless we feel it is necessary to split the transition-related items out or repeat them in a separate section.

  • The Backward compatibility section has been significantly expanded and makes it clearer in which cases things may not be backward-compatible. In particular, this expliclty mentions the pip freeze problem raised by @bwoodsend and @pf_moore.

  • The PEP now mentions explicitly what should happen if an invalid extra is specified for a package, in the case of tools that do not error when invalid extras are encountered (originally requested by @notatallshaw).

Open questions

The PEP explicitly mentions an open question that was raised and unresolved in the previous discussion thread. The PEP currently states that package[] is equivalent to package, but we could also potentially choose package[] to mean ‘no default extras’. It’s not clear yet whether this would be technically feasible, but it would be worth discussing whether it would be desirable if it was possible.

Thanks, and looking forward to the discussion!

Tom

20 Likes
2

I’m commenting in my capacity of the maintainer of conda packaging for astropy. I think this PEP would be helpful for conda packagers because it clarifies what the default plain install should be. In the case of astropy it has been challenging to decide what dependencies should be included in the conda package. Adopting this PEP would make that much clearer – the conda package would include as dependencies whatever gets installed when you pip install astropy.

3 Likes
3

I have a lot of thoughts about the package[] syntax – thanks for putting it in the open issues! – but I want to focus on the main one which I think is the primary driver of my view that it should mean “no extras”.

Which of the following two is the normal case and which is the exceptional case?

  • the package supports installation without its default extras
  • the package does not support installation without at least one extra, but any extra will do

I think the current PEP text has this backwards. It says that if I want to allow users to install my package without the default extras, I, as a package maintainer, need to devote extra thought and effort to the process. I have to choose a name like minimal and document it. It’s not much effort but it’s something a maintainer may not realize they need to do and users need to figure out on a per package basis.

Conversely, the “requires at least one extra” semantics, which are presented as desirable, I think are very, very rarely correct. It supposes not only that there’s some pluggable system, but also that

  • no extras are used for purposes other than that plug-in system
  • users are not allowed to bring their own plugins to the framework

Maybe this is a sign that I don’t work in domains where this is common, but I’ve never seen a package which works like that.

If wanting to support an install without the default extra is the normal case, then we should have support for that baked in.
As a secondary matter, I think package[] is the right way to spell it, but I’d like us to discuss the underlying issue first.

Thanks again for this PEP! I think it’s coming along nicely. :+1:

3 Likes
4

Which of the following two is the normal case and which is the exceptional case?

  • the package supports installation without its default extras
  • the package does not support installation without at least one extra, but any extra will do

I think the current PEP text has this backwards. It says that if I want to allow users to install my package without the default extras, I, as a package maintainer, need to devote extra thought and effort to the process. I have to choose a name like minimal and document it. It’s not much effort but it’s something a maintainer may not realize they need to do and users need to figure out on a per package basis.

Conversely, the “requires at least one extra” semantics, which are presented as desirable, I think are very, very rarely correct. It supposes not only that there’s some pluggable system, but also that

  • no extras are used for purposes other than that plug-in system
  • users are not allowed to bring their own plugins to the framework

Maybe this is a sign that I don’t work in domains where this is common, but I’ve never seen a package which works like that.

A semi-frequent example from projects I work on: you need a relational database, and so Python bindings for it. You choose to support multiple database backends (say… MySQL and Postgres) but don’t want users to end up having to install bindings for both when they’re only going to use one. You also want to support one of these by default so that users don’t mistakenly install your project without any bindings at all.

And yes, I know “just use an ORM and stop caring about SQL dialects” is the more common choice these days.

1 Like
5

(Edit: My next response, to @fungi’s post, explains my position much better than this one does.)

I sort of feel the opposite - because it’s expected to be uncommon, projects are likely to forget to add a minimal extra (or deliberately omit it to signal that it’s not officially supported). But it’s still going to be needed on occasion, so having a standard way to spell it ensures that users can’t be “locked out” of the minimal install (the case of someone developing a new backend being the obvious example of someone needing this even though it might not be supported).

I think it’s important to remember that having a default extra at all should be a very uncommon case. Extras are designed to be just that - “extra” - and the vast majority of packages should just work with no extras at all installed. A package that needs at least one extra to work, but has a choice of possible ones available, is already an unusual case. As you say, it basically implies the project uses some sort of plugin system and the extras allow you to choose which plugin to install. In that case, not installing a plugin is itself another level of unusual - my impression is that it would typically be someone who has developed their own alternative plugin, and wants to use it in place of the standard ones.

That’s something that I would not necessarily expect the project author to anticipate, so the likelihood of there being no minimal extra is quite high, IMO. And therefore, having a standard way to spell that option, which doesn’t require the project author to make a special effort to implement it, seems like the right approach to me.

I’m not sure how this relates to the package[] syntax. This seems more like a general problem with the idea of there being just one default, as opposed to groups of extras, each group being able to have a default.

For example, if I have a library that takes marked up text and renders it, I can easily imagine having extras for the markup languages being supported, and for the output backends. Furthermore, a standalone cli extra adding a command line interface could easily be present. In this case, a default extra could include typical markup and output backends. But then, if I specify the cli extra, I suddenly get no backends. Or if I only want PDF output, I will get no markup languages supported unless I specify them myself. Here, there are three “groups” of extras - markup languages, output systems, and “general features”, each of which deserves its own default.

I don’t think this PEP is attempting to address a situation like this, but in that case, it should be explicit about that. It also needs to make sure that it isn’t making it harder for a future PEP to address this case - and at the moment, I think that’s a problem, because the “include any extra and the default extra is omitted” rule does interfere with that case, as I showed above.

2 Likes
6

This is the canonical example of the use case the PEP is trying to support, I believe. And I’m fine with it. But:

  1. Someone developing a new database backend will need to request that the default extra isn’t installed, and your project may not have implemented a “without a database backend” extra, as it makes no sense for the average user.
  2. Your project is used in conjunction with a graphics library that supports multiple rendering engines. How does that combined project specify a combined set of extras that provides a useful default, and allows the user to select a different database backend without needing to know (or care) about the rendering backends - or vice versa?
2 Likes
7
  1. Someone developing a new database backend will need to request that the default extra isn’t installed, and your project may not have implemented a “without a database backend” extra, as it makes no sense for the average user.

At least in the projects I work in, it’s open source. They should feel free to create a derivative and modify it to their heart’s content, or collaborate upstream to get their new backend supported officially.

  1. Your project is used in conjunction with a graphics library that supports multiple rendering engines. How does that combined project specify a combined set of extras that provides a useful default, and allows the user to select a different database backend without needing to know (or care) about the rendering backends - or vice versa?

Yes, this is a usability conundrum, which I think gets us back to the same old “Python packaging is good for people who want to distribute libraries, not for people who want to distribute applications” and so the proposed PEP could rightly be viewed as yet another attempt to shoehorn application needs into a library model. Then again, so could the entire idea of extras.

I can see an argument that complex applications are better off asking for no extras (not even default ones), and really as few auto-installed transitive dependencies as possible, so that they can all be specified more accurately at the application package level. I suppose this is related to the recommendation that libraries try to be as loose as possible with version specs on their dependencies as well.

1 Like
8

Sure, but this is just busywork when starting the new backend project–either they’re engaging with another group (who is surely busy with their own priorities) or they need to maintain a fork and keep it up-to-date as they develop their project.

I definitely agree with @sirosen that there should be a standard way to specify “no extras”, and project[] seems like as good a way as any to do so[1]. You just never know how people are going to use something.

The downside I can imagine is that projects that don’t consciously specify a minimal install are going to develop their project mostly in ignorance of the separation between their default extra and the minimal one, and this will lead to problems for people trying to use the minimal install. But that’s something they can decide to explicitly support or not as the need arises, I suppose.

  1. the other option I can imagine is a standard keyword, but that seems more difficult to agree on ↩︎

2 Likes
9

I like the PEP a lot and hope it will be approved. But I do agree that it seems logical to define package[] as not installing any extras, also not the default ones. This seems a logical consequence of having the default be omitted if extras are specified and thus makes it easier to teach (otherwise, why is [] special in still giving you a default) and avoids having to explicitly define an extra with no dependencies.

The case for the different backends seems insufficiently strong to change this - it does not seem strange for package installation instructions to tell that users can get a working version with either pip install package or pip install package[backend] (and developers that if they want to experiment with a new backend they are designing, they should use package[]).

I should note, though, that I have not read the previous thread; maybe there were stronger arguments against package[]?

1 Like
10

I feel like this PEP is mixing a number of different issues/usecases and not solving most of them well (because it conflates defaults with missing metadata):

  1. The "pick (at least) one, but required": this is the db backend driver case (e.g. you you use SQLite or MySQL or PostgreSQL). What would solve this correctly is the ability to specify OR as well as AND in the resolver (this would require new syntax, and probably shouldn’t be done with extras). I’m not sure how RPM/DNF solves this, but for APT, the process is to take the first of the ORed options if one of the existing options isn’t to be installed (so choosing between the different options could be done via extras).
  2. The “pick the one suited to your system (required)”: this covers things like picking the appropriate QT backend to choose or which machine learning/AI libraries to use. This I think is better solved by being able to more specific wheels/being able to feed back to installed aspects of the system, though I think this is a really hard problem to solve (given the need for coordination between many different groups).
  3. The “novices vs. developers” or “data scientists want a black box”: this I think is really due to a subsection of the community using python as an incidental tool (and who would much rather not and get back to doing science) and have been told to use “astropy and jupyter notebooks” to do some task, and are hence confused when they need to install additional packages (because packages like astropy due to historical reasons such as packaging issues and needing to unify efforts have accumulated lots of functionality from which users need different 10%s). However, said packages are also used by developers (of which I am one :wink: ), who want to have smaller installs/containers (because the extra packages do add significant overhead, otherwise they’d be made into dependencies), so there are lots of extras. The linux distros have encountered this kind of issue before, and they have two solutions (which run in parallel):
    a. A system-wide toggle as to whether to consider by default recommends as required or not (this is system-wide because you want to ensure consistency of the install).
    b. Additional metadata which more novice friendly (and graphical) installers which call the traditional installers underneath so that when someone asks for “Firefox” they get the firefox package, but also all the language packs (or if the high-level installer is smart enough, the language pack for the configued language).
    Doing both a) and b) in the Python ecosystem seems plausible (Anaconda Navigator is an implementation of b, though as far as I know whatever metadata it uses is bespoke), and adding a toggle to consider whether recommends are required or not seems reasonable (and then rather than causing some_package==1.0 to mean different things as to whether default extras are specified (and hence adding effectively a breaking change), it’s instead a well defined requirement and what is installed is based on how the installer is configured (in the same way a different set of packages would installed if a constraints file was passed in).
  4. The “quickstart extra”: this is similar to 3 except the users are developers, instead they’re trying to pick up a new ecosystem. This feels like an argument of whether things should have batteries included and how should discovery/recommendations be passed on. This is different to 3 in that the users probably will want to at some point switch from using the quickstart extra to being more specific (whereas in three it’s two different user groups, and transitions between are rare). This feels like it could be solved in the project docs, but could use the recommends extra metadata as a hint.

So to summarise (because this has got far too long): Add the recommended extra, tooling targeting developers should by default not enable recommends (with toggle enabled), tooling targeting novices/data scientists (which is usually what they’re using anyway) should enable recommends.

1 Like
11

This is pretty much the canonical example I have in my head! But users should be allowed to define their own database adapter, right? Maybe they’re using some SQL-lookalike product like Snowflake or AWS Athena and want to plug it in.

If we agree that such a thing should be allowed [1], then we agree that it should be possible to deselect the default. But that’s not what the PEP says – the PEP says that if you defined support for mysql and postgres and didn’t explicitly build a way to opt out, then users of your package are stuck with those choices.

I find it interesting that we’re holding opposite ends of this but reason to a very similar place!

I’m of the mind that almost anyone defining a default would want to let their users opt out. If they didn’t want to let users opt out, why is it a default extra rather than part of the requirements?

So we should make that easy for package authors so that they can’t forget and it isn’t another fiddly thing for them to work through.

I read your posts as saying that because it can be forgotten, it very often will be forgotten. And that the end result is a degraded user experience. I agree with that being the consequence for sure! I’m less certain that package maintainers will overlook this, but I’m not sure that point of disagreement is of much consequence.

I think it’s related in that not having a built in way of spelling “disable the default extra” means that a package maintainer can exert more control over how users install the package.

To stick with the DB oriented examples we’ve been using in this thread, it allows a package maintainer to say that the following three specifiers are the only valid ways to install:

mypackage  # defaults to mysql
mypackage[mysql]
mypackage[postgres]

I think I’ve been clear that I don’t think such a package should forbid me from trying to write my own database adapter. Maybe for something like the SQL options given, like Oracle DB, or maybe for something unalike, such as Elasticsearch.

If we don’t provide a syntax for disabling the default extra, then we allow such a package to be defined. The PEP appears to be doing so intentionally. But I don’t think this use case is something we want to support – letting package maintainers dictate that users can choose an extra but that they must choose at least one.

Because I disagree with the underlying rationale for disallowing a “no extras” syntax, it connects back to package[]. The PEP rejects it in order to make room for a kind of package which I don’t think should exist.

If a package defines a default extra which it actually requires, then those dependencies should just be part of its requirements. To me, the scenario you describe would be a package with bugs in its published metadata.

Which doesn’t mean that it won’t happen! Nor that we should not care if we’re making that situation easier to create! But I’m not sure that default extras make this more of a problem than extras already do.

Defining extras lets package authors define a matrix of ways of installing their package. With N extras you have 2^N possible combinations. You don’t need to test that whole matrix but you really should test a reasonable slice of it. Otherwise, you’re publishing something untested.

I don’t think that tooling separation is possible.
pip and conda directly serve multiple communities and audiences. It’s good for tools to be aware of who their target users are, but some tools have target users of “everyone using Python”.

I’m not clear if you’re saying you want the default extras, as proposed, to be downgraded to a new and different field for recommended extras?
If so, I think that’s a perfectly reasonable alternative idea, but it’s quite different in scope. It would definitely mean that pip would have to ignore the data, which dramatically reduces the utility of defining such a thing.

I agree with a lot of what’s been said above about usability when there are multiple different requirements (e.g., pluggable backend and pluggable frontend), but I don’t think those issues are something the PEP can address without significant reshaping into something else. I’m of the opinion that these should be acknowledged as unsolved issues, but that we shouldn’t try to handle that here.
Maybe I’m giving up too early, but I don’t see a way of fitting that in with defaults – I think it just has to be done in documentation.

  1. From later in the thread, I think we are in agreement on this. But it’s hard for me to tell for sure. ↩︎

1 Like
12

But users should be allowed to define their own database adapter, right? Maybe they’re using some SQL-lookalike product like Snowflake or AWS Athena and want to plug it in.

In my experience, this requires at least trivial patching of the software (otherwise you’d be using an ORM to abstract away all the dialect differences anyway). If someone already needs to patch the software, making it easy to override packaging dependency choices doesn’t really help much, they can patch that bit too while they’re at it. And pretending that it’s likely to work gives users a bad taste in their mouths when they inevitably discover it’s not as simple as they were led to believe.

But this was merely an example, I’m sure there are other cases were that sort drop-in replacement works just fine.

13

Just for completeness - the idea above is essentially a variant of the rejected alternative Relying on tooling to deselect any default extras. As mentioned by @sirosen, the main issue here is that many tools serve both advanced and non-advanced users, so you couldn’t really say e.g. pip should install recommended dependencies by default, and uv shouldn’t.

Having said that, to be clear, tools could choose with the current PEP to install a command-line flag that would automatically disable all default extras in an install command, e.g. pip install --no-default-extras but we explicitly leave that to packaging tool maintainers to decide:

Nevertheless, this PEP does not disallow this approach and it is up to the maintainers of different packaging tools to decide if they want to support this kind of option.

(after all, it would be overreaching for the PEP to specifically disallow that tools implement this)

14

100% agreed. In my view, this is at the core of what Python’s “consenting adults” principle implies. Code authors should be able to suggest, but not dictate how users will use their code.

I mostly agree with this comment. However, I do think that there’s a risk that if we implement this proposal, we risk significantly limiting the available “design space” for handling the multiple-requirements space.

IMO, the PEP needs to acknowledge this use case. Maybe in the “rejected ideas” section, but if so then it needs to either explain why this proposal won’t harm future work on that case, or why the authors of the current proposal don’t care about that (maybe because they can show evidence that the multiple-requirements use case is vanishingly rare in practice).

3 Likes
15

You’ll still need some kind of override unless you expect a lot of quick releases from packages which depend on a package which introduces default dependencies (and local forks, because Python packaging explicitly blocks updating old releases, and this is ignoring less maintained packages), because as soon as a raw package name appears, you get the default extras. This is a significant amount of churn, and there are other flow on effects:

  1. Lock files have to track extras, because you can’t verify them if you don’t know if you should include the default extras or not (this should probably be raised in the lock file thread).
  2. Cycles need special handling (as called out in the PEP), which is avoided by not defaulting with recommends on.
  3. Packages with defaults are going to be rare (because there’s going to be implicit pressure to avoid them and to get dependants of packages with default extras to disable them where they exist if they are on by default), so users (and package developers) will only find out about them when something has gone wrong.

Default extras being defined but not on preserves the status quo (so there is no major migrations as would happen with them default on), but also means that they can be used more widely (because the negative aspects are avoided) and hence more users and packages can benefit (e.g. that there are default extras can displayed on PyPI).

16

I like this! :rocket:

This would be very useful for some packages I’ve created, in particular for: fastapi, typer, sqlmodel.

Additional Details and Current Workarounds I Have

No need to read below this point, it’s only for completeness and to share more info about my use cases in the packages I own and how this would be useful in each case.

TL;DR: I support this PEP, I would love to have this.

FastAPI

For FastAPI, I wanted to make it easier for people to get started with sane defaults. This included a CLI fastapi-cli, a web server uvicorn with its own recommended defaults, e.g. with uvloop for performance.

First, I tried to have a fastapi-slim package that would be equivalent of this PEP’s proposed fastapi[minimal], and then the regular fastapi would have the recommended default extra packages.

Both packages would export the importable fastapi, but that became problematic, in some cases overwriting one package’s files over the other after updates, and having one depend on the other also created some issues. Also the fact that the bare bones one was now a new package instead of the already existing fastapi one was problematic for some users.

In the end, I reverted it to have the current fastapi[standard], but that’s currently not ideal as some users naturally don’t realize they should install this specific extra to get the recommended defaults.

It would be great to be able to have recommended default extras for fastapi, and allow people to use fastapi[minimal] to opt-out if they want, while being the same fastapi package.

Typer

For Typer I wanted to recommend and (optionally) use Rich by default to provide nice looking CLIs. But if people didn’t install Rich, they wouldn’t have that, not knowing that they could “opt in” to a better result.

I still wanted to make it optional in case anyone, for some reason, needed bare bones minimal install.

In this case, I still have the approach of two packages, typer which includes Rich (and a couple of other things to improve shell completion install, etc), and typer-slim which is exactly the same package and exports the same importable typer module, but without the extras.

It would be great to be able to get rid of typer-slim and support a bare-bones minimal install with typer[minimal].

SQLModel

In SQLModel I still don’t use default extras, but I will need them, it will have a CLI, that will wrap Alembic to run migrations, so it will need at least those extras to work, which I expect most people will want to have, but it would be great to be able to also support a bare-bones minimal install as well with sqlmodel[minimal].

8 Likes
17

I disagree here: once it’s possible to define a default extra, I expect quite a few packages will move currently-required dependencies to a default-extra, and some will adopt further default dependencies on this basis. Often the package will “work” without some dependency, but work better with it.

As a maintainer, I’m trying to balance the interests of my users who want minimal dependencies, and the far more common case of naive users who don’t know about extras. So do I e.g. depend on a syntax-highlighting package by default, or not? Currently Hypothesis has decided no, and Pytest yes - but in both cases I’d like to make this a default-extra requirement!

10 Likes
18

I’d also prefer to have a standardised spelling of ‘package, but not its default extras’, whether that’s package[] or something more explicit like package[-] or package[.nodefaults]. My rationale:

  • I’d like to be able to specify this without having to work out what the package author decided to call the ‘minimal’ option (or if they omitted it altogether).
  • I think that the ‘recommended but not essential’ case is likely to be substantially more common than the ‘alternative backends’ one. I run into the former periodically, but I think there are only a handful of cases for the latter.
  • If you install something that needs one backend and explicitly opt out of its recommendations, I don’t really see it as a problem that you need to do something else to get it working.

To make a more concrete case, look at QtPy. This is an abstraction layer over different Qt bindings, and it can only be imported if at least one of those bindings is present. It seems to be a textbook case for not defining a ‘minimal’ extra, but I believe even this wants one. Let’s imagine that QtPy makes pyqt5 a default extra…

I maintain a Python + Qt package which depends on QtPy to support multiple Qt bindings. Say some application code depends on PySide6 plus my adeqt package. If adeqt specifies QtPy & gets its default extra, the app now gets a second set of Qt bindings installed. So for adeqt I want QtPy[minimal] as a dependency, because it’s up to the application to pick which Qt bindings to use.

It’s possible in that scenario for adeqt to expose the same 4 extras as QtPy, and use them just to select the corresponding extra on QtPy. But it’s much simpler, to my mind, for adeqt to depend on QtPy with no backend, as it currently does, and leave it up to the app to require one of the bindings.

5 Likes
19

Anything that would require an extension to PEP 508 (such as package[-] or package[.nodefaults]) would be a hard backward compatibility break in that if this appeared anywhere in a dependency tree, all but the most recent versions of pip (or other similar tools) would crash. This is the same reason that we discarded the idea of deleselecting extras using a - syntax - see Syntax for deselecting extras for the full rationale for rejecting this.

On the other hand, there is no way we can pick a valid extra name and not run the risk of clashing with existing extras used in packages (for example we can’t standardize [minimal]).

This leaves package[] as the only option of a universal option for saying ‘no default extras’. And it is actually a good option for backward compatibility: packages could depend on package[] and it would work with both installers that don’t recognize PEP 771 (and indeed not install any defaults) and it would work for older versions of package that don’t define default extras.

3 Likes
20

With the current approach in the PEP, I think the only solution to this specific use case is to assume that if users are reading the documentation anyway to find out how to opt in to specific non-default frontends, that same documentation should make it clear that if they explicitly specify the frontend, they have to specify the backend too - this could still take the form of a generic extra name so that they don’t actually have to care about which one to choose, so e.g.:

pip install package  # installs recommended backend and frontend
pip install package[]  # installs no backend or frontend
pip install package[defaultbackend, pyqt6]  # installs default backend and specific frontend
pip install package[sqlite, pyqt6]  # installs specific backend and frontend

Essentially, I think either users are ignoring the docs (in which case they won’t know about the extras), or they are reading it and hopefully can be shown how to make things work.

2 Likes