CODEWITHSUNDEEP
pythonpython-poetry
Daan Klijn
Daan Klijn

Reputation: 1684

Poetry ignore dependency in pyproject.toml

I currently have a Python3 project set up with Poetry as the main package manager. Next to that I also have set up a build and some automated testing via Github workflows. My package depends on Tensorflow, although the automated tests can run without it. Unfortunately Tensorflow (which is quite big) is installed every time the Github workflow runs these tests. As Tensorflow is not needed for these tests and as I would like to speed up my build, I would like to ignore the Tensorflow dependency when poetry install is called from the build pipeline.

Does anybody know a way to exclude a dependency when using Poetry?

Upvotes: 14

Views: 30078

Answers (2)

Daan Klijn
Daan Klijn

Reputation: 1684

I currently solved this by automatically removing the Tensorflow lines from the pyproject.toml on every build. After that, I also lock poetry again before the dependencies are installed. This is kind of a workaround, therefore I am still looking for a cleaner solution.

sed '/tensorflow/d' pyproject.toml > pyproject2.toml
mv pyproject2.toml pyproject.toml
cat pyproject.toml
pip install poetry
poetry run pip install --upgrade pip
poetry lock
poetry install

Upvotes: 3

Arne
Arne

Reputation: 20167

The only other approach that comes to mind would be to move the tensorflow dependency to an extra category, which in poetry would look like this:

$ poetry add --extras tensorflow

This means that it won't be installed when you run poetry install, unless it is part of a named group that you install explicitly. This can be achieved by adding this to your pyproject.toml:

[tool.poetry.extras]
runtime = ["tensorflow"]  # any name goes, I chose "runtime"  because it sounded like it'd make sense

The list can be extended with any other package that you only need during runtime, and not during tests. If you want to install your code to actually run it, you'll have to execute this before:

$ poetry install --extras runtime

This will cleanly separate your dependencies, you'll have to evaluate whether it makes sense in your case. As a rule of thumb, it's usually better to run hacks to make tests work rather than worsen the client experience, so your current workflow has a good chance of being better than what I just wrote.

Upvotes: 15

Related Questions