Not creating the requirements.txt file

[wshayes]

Summary

requirements.txt file was not being auto-generated when running poetry lock after installing the plugin

Background:

1. Setup the export in the pyproject.toml file like so:

[[tool.poetry-auto-export.exports]]
output = "requirements-dev.txt"
without_hashes = true


[[tool.poetry-auto-export.exports]]
output = "requirements.txt"
without = ["dev"]
without_hashes = true

2. Installed the plugin via pipx inject poetry poetry-auto-export

3. Checked that the plugin was installed using poetry self show plugins

Result:

Was not getting the requirements.txt and requirements-dev.txt files being generated when running poetry lock

Potential fix:

When I commented out the following lines in the plugin, it worked fine. I'm not sure why that check exists.

https://github.com/Ddedalus/poetry-auto-export/blob/ce6593567a617ec88878442134b9d330310b82db/poetry_auto_export/plugin.py#L31C1-L32C27

PS - thank you so much for creating this plugin - I'd finally gotten fed up after forgetting to update this way too many times when working with docker and your plugin magically showed up when I did a search for something like this.

[Ddedalus]

Hi, thanks for reporting!

The fact that the plugin works once you comment out the lines proves that:

• you've installed the plugin correctly
• the problem is related to the pyproject.toml parsing logic

The lines you're refering to ensure that the tool section in the pyproject is what we expect. They are needed because the plugin runs on any poetry command and hence must not error out on a variety of edge cases, e.g. when you run install for the first time on a new project, the tool section may be empty. In normal circumstances it should be an instance of tomlkit Table.

In the PR above I tried to reproduce the problem by using tomlkit directly to parse an example file. The test passes.
To help debug this further, could you:

• provide an entire pyproject file that causes the issue (you can trim it down and test locally in a new poetry env)
• manually add a print statement next to the lines you've commented out to check what the tools variable is and its type, e.g.

  print(tools)
  print(type(tools))
  

Given this information, we can hopefully create a failing test case for me to address or find a formatting problem in your pyproject.toml

[martinmoldrup]

I have the same issue. Commenting the lines out wshayes mentions also fixes it for me. Thanks for the plugin :)

[tool.poetry]
name = "SomeName"
version = "0.1.0"
description = ""
authors = ["Me"]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.10"
promptflow = "1.6.0"


[tool.poetry.group.dev.dependencies]
pytest = "*"
pytest-cov = "*"
flake8 = "*"
flake8-docstrings = "*"
mypy = "*"
isort = "*"
autoflake = "*"
yapf = "*"


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"


[[tool.poetry-auto-export.exports]]
output = "dev-requirements.txt"
without_hashes = true

[martinmoldrup]

I have the same issue. Commenting the lines out wshayes mentions also fixes it for me. Thanks for the plugin :)

[tool.poetry]
name = "SomeName"
version = "0.1.0"
description = ""
authors = ["Me"]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.10"
promptflow = "1.6.0"


[tool.poetry.group.dev.dependencies]
pytest = "*"
pytest-cov = "*"
flake8 = "*"
flake8-docstrings = "*"
mypy = "*"
isort = "*"
autoflake = "*"
yapf = "*"


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"


[[tool.poetry-auto-export.exports]]
output = "dev-requirements.txt"
without_hashes = true

[Ddedalus]

Thanks @martinmoldrup. I was able to reproduce and fix the issue with the file you've provided.
The problem here is related to some weird (but apparently useful) guts of tomlkit.

I've added a test for this case and relaxed the type check a bit in #8 . I'll create a new release shortly. Could you update the package and let me know if it works for you? @wshayes , I hope this solves your problem as well!

[slovdahl]

I had the same problem as the reporter had, and I can confirm that 0.2.1 fixes the problem for me at least.