# How specify a lib dependency **URL:** \ **Category:** Python Help\ **Tags:** help, packaging-help\ **Created:** [January 27, 2024, 12:50am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259 "2024-01-27T00:50:11Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![EdmundsEcho](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/edmundsecho/32/14088_2.png) [@EdmundsEcho](https://discuss.python.org/u/EdmundsEcho)\ **Post date:** [January 27, 2024, 12:50am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/1 "2024-01-27T00:50:12Z")
I’m using a pyproject.toml file to specify the depencies. I have multiple packages within my project. Each package has it’s on pyproject.toml. So, something like a workspace in the Rust world. ```fish 📂 . ├──  lib │ ├── 📂 luci │ │ ├── 📂 core │ │ ├──  pyproject.toml │ │ ├── 📂 tests │ │ └── 📂 tnc_connector_core.egg-info │ └── 📂 luci-postgres │ ├── 📂 postgres │ ├──  pyproject.toml │ ├── 📂 tests │ └── 📂 tnc_connector_postgres.egg-info ``` The postgres package depends on the core package. Is there a way to specify the dependency in the pyproject.toml file? ---
**Author:** ![MariaBu](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@MariaBu](https://discuss.python.org/u/MariaBu)\ **Post date:** [January 27, 2024, 7:04am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/2 "2024-01-27T07:04:19Z")
> [@EdmundsEcho](#): > > Each package has it’s on pyproject.tom There are Tutorials on packages and depencies [Tutorials](https://packaging.python.org/en/latest/tutorials/) That talks about a pip file [pipfile](https://packaging.python.org/en/latest/key_projects/#pipfile) Now you say: **Each package has it’s on pyproject.toml** What I see instead is just 1 such file for a big project. I’m not sure if that than would interact with the several pyproject.toml for each project underneath like you want it. I could think of creating an entire new pyproject.toml covering all the dependencies you need. But that is a pain and can easily cause mistakes. May be a bit of scripting to collect dependencies from each single pyproject.toml and write them into a new file could be an idea. Then copy over the outcome into the pyproject.toml file for the greater project now. ---
**Author:** ![cameron](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cameron/32/2658_2.png) [@cameron](https://discuss.python.org/u/cameron)\ **Post date:** [January 27, 2024, 7:04am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/3 "2024-01-27T07:04:34Z")
PEP 621 specifies this stuff. You want the `dependencies` section of the `[project]` table: > **[PEP 621 – Storing project metadata in pyproject.toml | peps.python.org](https://peps.python.org/pep-0621/#dependencies-optional-dependencies)** > > Python Enhancement Proposals (PEPs) Note that in the TOML file, the `project` is your package. As an example, the `pyproject.toml` for my `cs.x` package starts like this: ``` [project] name = "cs.x" description = "X(), for low level debugging." authors = [ { name = "Cameron Simpson", email = "cs@cskk.id.au" }, ] keywords = [ "python2", "python3", ] dependencies = [ "cs.ansi_colour>=20220227", "cs.gimmicks>=20230331", ] classifiers = [ "Programming Language :: Python", "Programming Language :: Python :: 2", "Programming Language :: Python :: 3", "Development Status :: 4 - Beta", "Intended Audience :: Developers", "Operating System :: OS Independent", "Topic :: Software Development :: Libraries :: Python Modules", "License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)", ] version = "20231129" ``` ---
**Author:** ![cameron](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cameron/32/2658_2.png) [@cameron](https://discuss.python.org/u/cameron)\ **Post date:** [January 27, 2024, 7:09am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/4 "2024-01-27T07:09:08Z")
> [@MariaBu](#): > > Now you say: **Each package has it’s on pyproject.toml** > What I see instead is just 1 such file for a big project. I’m not sure if that than would interact with the several pyproject.toml for each project underneath like you want it. By contrast, I keep my personal modules/packages in a single monorepo, much like the OP is above. It’s reasonable to have a `pyproject.toml` for each package if that’s how you’re working. ---
**Author:** ![MariaBu](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@MariaBu](https://discuss.python.org/u/MariaBu)\ **Post date:** [January 27, 2024, 7:31am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/5 "2024-01-27T07:31:24Z")
o.k. Postgres depends on Core [writing project.toml](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/) When on the page scroll down to: ## Dependencies and requirements ### `dependencies`/`optional-dependencies` If your project has dependencies, list them like this: [project] dependencies = [“httpx”, “gidgethub[httpx]\>4.0.0”, “django\>2.1; os\_name != ‘nt’”, “django\>2.0; os\_name == ‘nt’”, ] See [Dependency specifiers](https://packaging.python.org/en/latest/specifications/dependency-specifiers/#dependency-specifiers) for the full syntax you can use to constrain versions. You may want to make some of your dependencies optional, if they are only needed for a specific feature of your package. In that case, put them in `optional-dependencies`. [project.optional-dependencies] gui = [“PyQt5”] cli = [“rich”, “click”,] Each of the keys defines a “packaging extra”. In the example above, one could use, e.g., `pip install your-project-name[gui]` to install your project with GUI support, adding the PyQt5 dependency. ### `requires-python` This lets you declare the minimum version of Python that you support [[1]](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#requires-python-upper-bounds). [project] requires-python = “\>= 3.8” ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [January 27, 2024, 5:38pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/6 "2024-01-27T17:38:43Z")
Thanks for showing the structure of your project; its very helpful in giving you advice specific to your situation. One key point to get out of the way first, in case you (or others) aren’t already aware, is the overloading of the term “package” to mean two entirely different things “import package” and “distribution package” \[1\]: - An **_import package_** is any directory containing an ` __init__.py` file (and typically, Python code), and the name of that import package directory is what you _import_ in Python. - A **_distribution package_** is how your project is distributed to others (on PyPI, etc), and may contain one or more _import packages_. Each `pyproject.toml` corresponds to one distribution package, and the `project.name` specified therein is the name under which you find the project on PyPI, install it with `pip`, specify it as a dependency, etc. In your case, you have two top-level import packages, `core` and `postgres`. Each top-level import package is contained within its own distribution packages, with respective names `tnc-connector-core` and `tnc-connector-postgres` (I can see the names above due to using legacy editable installs with `.egg-info` files). `core` and `postgres` would be the names you’d `import` them under in Python, while `tnc-connector-core` and `tnc-connector-postgres` would be how you’d find and install them from PyPI, and how you’d specify them as dependencies. As others have mentioned, assuming you’re using a current version of any modern backend that supports pyproject (“PEP 621”) metadata (Setuptools, Flit, Hatch, PDM, Meson-Python, Scikit-Build-Core, etc, basically everything but Poetry) you can specify your project’s dependencies in `pyproject.toml` following the [standard specification](https://packaging.python.org/en/latest/specifications/pyproject-toml/#declaring-project-metadata-the-project-table), like this: ```toml [project] name = "tnc_connector_postgres" version = 0.2 dependencies = ["tnc_connector_core>=0.2"] ``` The deps specified in `pyproject.toml` are, in general, _abstract_ dependencies; they state what distribution package names and versions your project requires in order to function. However, what you _might_ actually be asking is for a way to tell packaging tools to build and install your dependency _locally_, rather than from PyPI by default. This corresponds to _concrete_ dependencies, i.e. specifying the _exact_ dependency versions and artifacts you want installed, and where to get them from. For that, you’ll probably want to use a requirements file or lock file for this purpose, which also lets you specify an editable install. Support for relative local paths [appears to be patchy at the moment](https://github.com/pypa/pip/issues/6112), but you _should_ be able to get it to work. * * * **Sidenote** : To note, giving the import packages such generic names if they aren’t going to be under another top-level import/namespace package (like `luci`) isn’t usually the best idea, since they will clash with any other import package that might happen to have such a generic name (e.g. e.g. a `postgres` binding library of that name, or `core` for another project you’ve created). The simplest solution is to incorperate `luci`, `tnc`, etc. in the import package (directory) name, e.g. `luci_core` or `tnc_postgres`. Alternatively, you could make a top-level `luci` [namespace package](https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages), so you’d have one top-level import package (`luci`, with your subpackages accessed by `luci.core`, `luci.postgres`, etc.) * * * 1. Note that I ignore namespace packages here as you don’t appear to be using them, they aren’t that common, and further complicate several of the points below ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [January 27, 2024, 5:59pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/7 "2024-01-27T17:59:25Z")
> [@MariaBu](#): > > That talks about a pip file > [pipfile](https://packaging.python.org/en/latest/key_projects/#pipfile) > > Now you say: **Each package has it’s on pyproject.toml** > What I see instead is just 1 such file for a big project. I’m not sure if that than would interact with the several pyproject.toml for each project underneath like you want it. To note, the OP is asking about specifying dependencies in their `pyproject.toml` files; `pipfile` is a file format specific to the legacy, no longer widely used `pipenv` packaging tool, and is not likely to be useful unless the OP already happens to be using that particular tool. However, the general approach of specifying local installation in a concrete dependency file is indeed what I’d suggest if the OP is actually looking for a way to programmatically specify editable installation of local packages. > [@MariaBu](#): > > I could think of creating an entire new pyproject.toml covering all the dependencies you need. But that is a pain and can easily cause mistakes. May be a bit of scripting to collect dependencies from each single pyproject.toml and write them into a new file could be an idea. Then copy over the outcome into the pyproject.toml file for the greater project now. I’m not really sure how this would really help, nor would be necessary, sorry—if the OP wants to specify dependencies for a specific distribution package, they merely use the `project.dependencies` key in that project’s `pyproject.toml`, while if they want an environment with all their top-level packages installed, a simple `requirements.txt` listing the top-level distribution package names will suffice, or if they do want an actual metapackage with a `pyproject.toml`, they only need list their top-level packages, in this case just `tnc_connector_core` and `tnc_connector_postgres` (and technically, the former could be omitted because its a dependency of `tnc_connector_prostgres`), which will produce the same result and is relatively easy to maintain manually. ---
**Author:** ![jeanas](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jeanas/32/8115_2.png) [@jeanas](https://discuss.python.org/u/jeanas)\ **Post date:** [January 27, 2024, 7:04pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/8 "2024-01-27T19:04:11Z")
AFAIU, the OP is looking for an equivalent of Cargo’s workspace feature, which allows you to _develop_ several packages at the same time in a mono-repo. The virtual environment used for development needs to have all the projects installed as editable, but the packages uploaded to PyPI also need to be installable. Cargo achieves this by rewriting metadata upon publishing; this would be an equivalent of rewriting `foo @ file://foo/` into `foo` in the `pyproject.toml` file. AFAIK, none of the current workflow tools (Hatch, PDM, Poetry, Flit) supports this. So the only solution is to specify dependencies normally, with only the name of each package, and in order to develop the package, create the virtual environment manually, using `python -m venv; venv/bin/pip install --editable subpackage1/ --editable subpackage2/` instead of relying on `hatch shell`, `poetry update` or the like. ---
**Author:** ![kknechtel](https://avatars.discourse-cdn.com/v4/letter/k/e47c2d/32.png) [@kknechtel](https://discuss.python.org/u/kknechtel)\ **Post date:** [January 28, 2024, 5:23am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/9 "2024-01-28T05:23:30Z")
> [@EdmundsEcho](#): > > The postgres package depends on the core package. Is there a way to specify the dependency in the pyproject.toml file? Yes; the same way that you would specify third-party dependencies - by using the `project.dependencies` table. Once you have made the choice to use a separate `pyproject.toml` per package (and thus, to distribute them separately), Python loses any reason to care about the containing `lib` folder (or any directories higher up in the tree). Alternately, you can make a PyPI package based off a single `pyproject.toml` in the `lib` root, and configure it so that `pip install` for that single name on PyPI installs all the code. IIRC, this can be done either such that the installed code has a corresponding containing folder (client code will see a single package with that name, and need to account for it in absolute imports; your code, if it uses relative imports, should work with the installed folder structure rather than the development folder structure) or as separate deliverables inside `site-packages` (client code will have two separate top-level absolute imports available; your code will still need to use absolute imports to access internal dependencies). ---
**Author:** ![kknechtel](https://avatars.discourse-cdn.com/v4/letter/k/e47c2d/32.png) [@kknechtel](https://discuss.python.org/u/kknechtel)\ **Post date:** [January 28, 2024, 5:53am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/10 "2024-01-28T05:53:20Z")
> [@CAM-Gerlach](#): > > One key point to get out of the way first, in case you (or others) aren’t already aware, is the overloading of the term “package” to mean two entirely different things “import package” and “distribution package” [[1]](#footnote-142068-1) > > : > > - An _ **import package** _ is any directory containing an ` __init__.py` file (and typically, Python code), and the name of that import package directory is what you _import_ in Python. > - A _ **distribution package** _ is how your project is distributed to others (on PyPI, etc), and may contain one or more _import packages_. Each `pyproject.toml` corresponds to one distribution package, and the `project.name` specified therein is the name under which you find the project on PyPI, install it with `pip`, specify it as a dependency, etc. IMO, we should have just called “import packages” _modules_ from the start (because they _are_), and referred to any modules contained within another module as “submodules”. That is, treat “this thing, despite being a coherent unit in itself, is part of a larger whole” as a special property of certain modules, rather than treating “this thing has components of the same kind” that way. Then “package” would only mean distribution packages, which would avoid tons of confusion (since, among many other things, “packaging” never seems to mean creating import packages). ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [January 28, 2024, 7:09am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/11 "2024-01-28T07:09:38Z")
I agree that in hindsight something like that would probably have been a lot better (or perhaps still calling (file) modules modules, and calling “import packages” module directories, directory modules, or basically anything other than packages, e.g. namespaces). At least point, the meaning of `module` as a single importable Python file is embedded enough into the language that I’m not sure its feasible to change the meaning, but I’m not sure its out of the question to change what we now call [import] packages to something else—though that would be a whole separate discussion, of course. It is important to keep in mind though that if we’re really talking “from the start”, back when import packages were first introduced (I can find them at least as far back as Python 1.5, dating from early 1998, over 25 years ago), there _wasn’t_ really any other “packaging” as we know it now; what we now call packaging didn’t really exist in general beyond mostly just copying files and directories (i.e. [import] packages) around; `distutils`, and thus the very bare rudiments of distribution packages, wasn’t added until almost 4 years later, with Python 2.2 at the very end of 2001, and PyPI wasn’t created until over 5 years later, in 2003 (and of course, it took many years after that for [distribution] packaging to really start to take off). ---
**Author:** ![petersuter](https://avatars.discourse-cdn.com/v4/letter/p/13edae/32.png) [@petersuter](https://discuss.python.org/u/petersuter)\ **Post date:** [January 28, 2024, 8:45am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/12 "2024-01-28T08:45:28Z")
> [@CAM-Gerlach](#): > > but I’m not sure its out of the question to change what we now call [import] packages to something else Great you’re coming around on this 😉 > [@Python packaging documentation feedback and discussion](https://discuss.python.org/t/python-packaging-documentation-feedback-and-discussion/24833/113): > > Right, though that documentation doesn’t discuss distribution packaging at all—there, “package” is only ever defined and used to mean an import package. Its certainly arguable that the unambiguous term should be used there as well, though as the reader will presumably read that tutorial as they are first leading how to program in Python, well before they get to sharing their code with others through distribution packaging and they are taught even what that is, it seems to me to be less potentia… ---
**Author:** ![MariaBu](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@MariaBu](https://discuss.python.org/u/MariaBu)\ **Post date:** [January 28, 2024, 10:43am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/13 "2024-01-28T10:43:52Z")
Thanks a lot for your detailed answer ---
**Author:** ![onePythonUser](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/onepythonuser/32/19158_2.png) [@onePythonUser](https://discuss.python.org/u/onePythonUser)\ **Post date:** [January 28, 2024, 1:26pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/14 "2024-01-28T13:26:20Z")
> [@CAM-Gerlach](#): > > An _ **import package** _ is any directory containing an ` __init__.py` file (and typically, Python code), and the name of that import package directory is what you _import_ in Python. Hello, I am reading **Learning Python, 5th Ed**. (2013). There, it states the following ( **Chapter 24: Module Packages** ): _As one consequence of this new import procedure, as of Python 3.3 packages no longer_ _require ` __init__ `.py files—when a single-directory package does not have this file, it will_ _be treated as a single-directory namespace package, and no warning will be issued. This_ _is a major relaxation of prior rules, but a commonly requested change; many packages_ _require no initialization code, and it seemed extraneous to have to create an empty_ _initialization file in such cases. This is finally no longer required as of 3.3._ Has this requirement been brought back? ---
**Author:** ![jeanas](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jeanas/32/8115_2.png) [@jeanas](https://discuss.python.org/u/jeanas)\ **Post date:** [January 28, 2024, 2:50pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/15 "2024-01-28T14:50:36Z")
This book is giving bad advice, in my opinion. Having no ` __init__.py` file is indeed allowed, but it will turn the package into a namespace package, which can have surprising consequences (a namespace package is a package that can be split across the file system, i.e., you can have different subpackages installed in completely different directories). Always use an ` __init__.py` file (even if empty) unless you specifically intend to create a namespace package. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [January 28, 2024, 4:04pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/16 "2024-01-28T16:04:54Z")
> [@onePythonUser](#): > > Has this requirement been brought back? I address this in both my footnote prior to the definitions: > [@CAM-Gerlach](#): > > Note that I ignore namespace packages here as you don’t appear to be using them, they aren’t that common, and further complicate several of the points below. And also in the sidenote at the end: > [@CAM-Gerlach](#): > > Alternatively, you could make a top-level `luci` [namespace package](https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages), so you’d have one top-level import package (`luci`, with your subpackages accessed by `luci.core`, `luci.postgres`, etc.). As I mention there, while I considered describing the caveat in the main text, I didn’t want to further overcomplicate the distinction, and so moved it to a footnote (which I tweaked to fix a syntax issue and be more visible). > [@onePythonUser](#): > > _This is a major relaxation of prior rules, but a commonly requested change; many packages_ > _require no initialization code, and it seemed extraneous to have to create an empty_ > _initialization file in such cases. This is finally no longer required as of 3.3._ As @jeanas mentions, the book is simply wrong, and quite badly so. Nowhere in [PEP 420](https://peps.python.org/pep-0420/) that introduced this to enable marking namespace packages was there even any mention of this very minor convenience factor having anything to do with the change. And furthermore, an ` __init__.py` is not “extraneous”, as the book speciously claims, but is an unambiguous marker of an otherwise ordinary directory being a Python package, avoiding a number of packaging, tooling and user issues and complexities that arise when this has to be implicitly guessed. ---
**Author:** ![onePythonUser](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/onepythonuser/32/19158_2.png) [@onePythonUser](https://discuss.python.org/u/onePythonUser)\ **Post date:** [January 28, 2024, 4:34pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/17 "2024-01-28T16:34:45Z")
> [@jeanas](#): > > This book is giving bad advice, in my opinion > [@CAM-Gerlach](#): > > the book is simply wrong, and quite badly so Thank you for responding and clearing this up. I will update my notes. I will make sure to include an ` __init__.py` file in my packages. Much appreciated. ---
**Author:** ![EdmundsEcho](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/edmundsecho/32/14088_2.png) [@EdmundsEcho](https://discuss.python.org/u/EdmundsEcho)\ **Post date:** [January 28, 2024, 8:24pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/18 "2024-01-28T20:24:16Z")
> [@CAM-Gerlach](#): > > However, what you _might_ actually be asking is for a way to tell packaging tools to build and install your dependency _locally_, rather than from PyPI by default. That’s correct. I don’t want to have to publish to PyPl in order to use the package as a dependency. I want a way to override the default to point to a local package to find the dependency. I also understand that would require I build the packages in a sequence that tracks the dependencies (so, build core first). ---
**Author:** ![EdmundsEcho](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/edmundsecho/32/14088_2.png) [@EdmundsEcho](https://discuss.python.org/u/EdmundsEcho)\ **Post date:** [January 28, 2024, 8:43pm UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/19 "2024-01-28T20:43:27Z")
Thank you for the concrete example. Prior to my posting I did read through the PEP docs. I couldn’t find an example of how to reference a “package” dependency found locally. Similarly for the spec that describes a dependency. Despite this, I was hoping there was a way that I had overlooked. ---
**Author:** ![EdmundsEcho](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/edmundsecho/32/14088_2.png) [@EdmundsEcho](https://discuss.python.org/u/EdmundsEcho)\ **Post date:** [January 29, 2024, 12:01am UTC](https://discuss.python.org/t/how-specify-a-lib-dependency/44259/20 "2024-01-29T00:01:31Z")
There have been a lot of great comments. So far I’m concluding that there is no way to use pyproject.toml to specify a locally hosted package. There might be a way using the requirements.txt file. This would involve building a whl file for `core` (I renamed it to `luci-core` per suggestions made elsewhere), and referencing that in the requirements.txt file for the `postgres` package (I renamed that to `luci-postgres`). So it looks like we can’t get rid of using requirements.txt in all cases when using pyproject.toml. [Next page](https://discuss.python.org/t/how-specify-a-lib-dependency/44259.md?page=2)