Exported requirements.txt contains spurious messages if lock file does not exist
- Poetry version: 1.3.2
- Python version: 3.10.6
- OS version and name: Ubuntu 22.04.1
- pyproject.toml: just create it with
poetry new poetry-demo:
[tool.poetry]
name = "poetry-demo"
version = "0.1.0"
description = ""
authors = ["Patrick Decat"]
readme = "README.md"
packages = [{include = "poetry_demo"}]
[tool.poetry.dependencies]
python = "^3.10"
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
- [x] I am on the latest stable Poetry version, installed using a recommended method.
- [x] I have searched the issues of this repo and believe that this is not a duplicate.
- [x] I have consulted the FAQ and blog for any relevant entries or release notes.
- [ ] If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption) and have included the output below.
Issue
When lock file does not exist, poetry export writes some messages to standard output:
# poetry --version
Poetry (version 1.3.2)
# poetry new poetry-demo
Created package poetry_demo in poetry-demo
# cd poetry-demo/
# poetry export -f requirements.txt > requirements.txt
The lock file does not exist. Locking.
Creating virtualenv poetry-demo in /home/patrick/workspaces/tests/poetry/poetry-demo/.venv
# cat requirements.txt
Updating dependencies
Resolving dependencies...
Writing lock file
Related:
- https://github.com/python-poetry/poetry/issues/4109
- https://github.com/python-poetry/poetry/issues/4110
poetry export -o requirements.txt
Hi @dimbleby, I know that option to output directly to a file, but as I need to post-process it to remove some dependencies which are provided by AWS Lambda python runtime, it is more practical to process the standard output directly, e.g.:
poetry export -f requirements.txt --without-hashes | grep -v '^\(boto3\|botocore\|s3transfer\)==' | tee layer/requirements.txt
Given precedent on python-poetry/poetry#4110, it was my impression redirecting standard output to a requirements.txt file or pipe it into another command was an accepted use case.
Isn't that the case anymore?
IMO it never was, but there's no harm in being helpful in the main line case.
Your particular sub-issue could also be solved by locking before exporting, which seems pretty reasonable.
Your particular sub-issue could also be solved by locking before exporting, which seems pretty reasonable.
Indeed. Anyway, we do have checks to catch this in our CI.