Wrong Poetry config is used when project is not in repository's root

[oranav]

Description:
When collecting Poetry projects for caching, a **/poetry.lock glob is used, meaning the action supports Poetry projects in subfolders.

setup-python/src/cache-distributions/poetry-cache.ts

Line 11 in ffcd000

protected patterns: string = '**/poetry.lock'

However, in order to process the Poetry configuration, getPoetryConfiguration runs the poetry command from the repo's root directory; this causes Poetry to return an invalid configuration when there is a Poetry project inside an inner directory.

setup-python/src/cache-distributions/poetry-cache.ts

Lines 45 to 48 in ffcd000

	const {stdout, stderr, exitCode} = await exec.getExecOutput('poetry', [
	'config',
	'--list'
	]);

Action version:
v4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

All Poetry versions

Repro steps:
Create a repository with a Poetry project inside a subfolder; use the default action configuration. Matter of fact, even if a specific cache-dependency-path is provided, the resulting Poetry config will still be invalid.

Expected behavior:
The correct pyproject.toml and poetry.toml (inside the subfolder) are used.

Actual behavior:
The read configuration uses pyproject.toml and poetry.toml from the repository root directory.

[IvanZosimov]

Hi, @oranav 👋 ! Thank you for this issue! We will investigate it and get back to you with updates 🖨️

[oranav]

@IvanZosimov I already have a draft PR here: #447, I just have to test it locally first (and maybe add a test)

[dsame]

Hello @oranav

Can you please help to reproduce the problem.
I tried to create the workflow according to the description and it looks like everything works as expected

This build creates the cache, you can see it from Post Run actions/setup-python@v4 step.

And next run of the same pipeline definitely uses the cache from the previous step because of the output of run says:

Installing dependencies from lock file
No dependencies to install or update

I suspect you missed the use of working-directory option of run action.

I believe the working-directory is the correct solution because it is possible to have few sub-projects and attempting to autodiscovery the sub-project could lead to the wrong decision.

Do you agree the working-directory works for this issue?

[oranav]

@dsame No, it's unrelated to setting working-directory. You're missing a poetry.toml file.

The whole point is that the action runs poetry config in the root directory, therefore it looks for poetry.toml there, instead of looking for it in the project directory.

Run poetry config --local virtualenvs.in-project true in the project directory - this will create a poetry.toml file. Commit it, and let the action run.
You'll see in its output virtualenvs.in-project = null, instead of the expected virtualenvs.in-project = true.

You can see it here.

[dsame]

Hello @oranav i am closing this issue because of related PR #447 has been merged, but please feel free to reopen it or create new one in case if the problem still exists.