Allow envvar POETRY_PROJECT_PLUGIN_CACHE to override plugin cache path

[colindean]

I observed a condition wherein two tests running concurrently with different versions of Python, thus different virtualenv paths, overwrote each others' .poetry/plugins directory since that is managed per-project.

Overriding the project plugin cache path with an environment variable set, e.g. .poetry_310/plugins and .poetry_314/plugins in the two concurrent CI jobs operating on the same working directory, would keep this from happening.

Pull Request Check List

Resolves: (None)

• [ ] Added tests for changed code.
• [x] Updated documentation for changed code.

Summary by Sourcery

New Features:

• Allow overriding the project plugin cache directory through the POETRY_PROJECT_PLUGIN_CACHE environment variable

[sourcery-ai[bot]]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Allow overriding the project’s plugin cache directory via the POETRY_PROJECT_PLUGIN_CACHE environment variable while falling back to the existing .poetry/plugins path.

Class diagram for updated ProjectPluginCache path logic

classDiagram
    class ProjectPluginCache {
        +PATH
        +__init__(poetry: Poetry, io: IO)
    }
    note for ProjectPluginCache "PATH is now set to os.environ.get('POETRY_PROJECT_PLUGIN_CACHE', Path('.poetry') / 'plugins')"

File-Level Changes

Change	Details	Files
Enable envvar override for plugin cache path	Swapped the fixed Path(“.poetry”)/“plugins” constant for os.environ.get("POETRY_PROJECT_PLUGIN_CACHE", default) Retained the original .poetry/plugins location as the fallback when the variable is unset	src/poetry/plugins/plugin_manager.py

Possibly linked issues

• #N/A: PR allows POETRY_PROJECT_PLUGIN_CACHE envvar to customize plugin path, resolving concurrent Poetry invocation issues.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an issue from a review comment by replying to it. You can also reply to a review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull request title to generate a title at any time. You can also comment @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in the pull request body to generate a PR summary at any time exactly where you want it. You can also comment @sourcery-ai summary on the pull request to (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the pull request to resolve all Sourcery comments. Useful if you've already addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull request to dismiss all existing Sourcery reviews. Especially useful if you want to start fresh with a new review - don't forget to comment @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[colindean]

I'm planning to refactor this to put the path in a static method but I need a little more IDE than single-file editing. My work VPN blocks Codespaces and I'm too close to the end of the day to set things up locally.

[radoering]

I observed a condition wherein two tests running concurrently with different versions of Python, thus different virtualenv paths, overwrote each others' .poetry/plugins directory since that is managed per-project.

Only Poetry's own Python version should be relevant, not the project's Python version. Do you use two different Poetry installations?

[colindean]

Do you use two different Poetry installations?

In this situation, yes, two different Poetry installations in separate containers running concurrently against the same project file system.

[radoering]

I wonder if this is too much of an edge case. (I am not strictly opposed. I just want to understand if it is worth it.)

Why not installing the required plugins together with Poetry in the container? Is a command to install the plugins that much more inconvenient than setting an environment variable?