poetry run: deprecate uninstalled entry points

[wagnerluis1982]

Pull Request Check List

• Added tests for changed code.
• Updated documentation for changed code.

Deprecating poetry run to execute uninstalled entry points.

Say I have the following entry point:

[tool.poetry.scripts]
dev = "my_package.main:run"

If I run poetry run dev, the sys.argv[0] is unpredictable and is confusing users:

• sys.argv = ['dev'] if script is not installed.
• sys.argv = ['/home/wagner/.cache/pypoetry/virtualenvs/my_package-Iqs9p7vq-py3.7/bin/dev'] if script is installed.

Refer to discussion #7599, to understand more of why this deprecation is important.

Sample output

[DMRobertson]

When I read

Deprecate poetry run <script> if the script was not previously installed via poetry install

in the 1.5.0 release notes I was a little alarmed. I thought that might mean that poetry run <shell commands> were being deprecated (e.g. poetry run black, poetry run mypy, ...). But I think this change only applies to entrypoints---is that correct?

[radoering]

Exactly, script as in [tool.poetry.scripts]. A deprecation warning will be printed if you run something deprecated.

[ericriff]

I was a bit alarmed as well. I suggest editing the release notes to make it more clear :)

[rowanseymour]

We've just started seeing build failures in Django projects that invoke manage.py e.g.

poetry run ./manage.py collectstatic --noinput

Command not found: ./manage.py
Error: Process completed with exit code 1.

I'm assuming this is related.. but I'm not sure what we're supposed to be doing instead.

[rowanseymour]

Apologies actually looking at what this PR changes hasn't caused that error above... still trying to find what has changed in 1.5.0 to affect this.

[ghost]

This is actually a huge dangerous change because we use the scripts features during development as utility launchers across dozens of projects. We only care about running scripts from the local directory and nothing ever gets "installed" across a dozen repos on our services.

This is maybe acceptable if there's a "dev mode" override where it doesn't complain or fail (because we don't need to run poetry install after every 3 character code change to run the next debug cycle).

This also broke our standard usage of poetry run ./script.py in a local environment too and it caused all our auto-rebuilding docker images over the weekend to fail rebuilding hundreds of times (why release huge breaking changes over a weekend??????).

Apparently only poetry run python ./script.py works now as previously it would properly run anything executable in the poetry-scoped venv.

[radoering]

@mattpeople Wrong PR. This one only prints a deprecation warning for entry points. The changelog entry is ambiguous (see #7958). You are experiencing a bug: #7959. The bug will be fixed in the next patch release.

[ghost]

oh, yeah this was conflating two things.

It took us a couple hours to narrow down why all our builds broke over the weekend because Docker just started reporting "Command not found" even though the file is right there! from all our poetry run ./start.py internal usage 😩

(i guess technically we shouldn't have our systems using pip install pip poetry -U without versions, but I like to see when new versions break instead of missing version updates for 3 years; we almost need a pre-CI for our CI or something).

but this "refuse pyproject scripts unless poetry install runs" also seems like it makes the usability worse for little benefit outside of rare edge cases? though, properly referencing the pyproject scripts inside multiple develop-mode dependencies has always been a bit tricky when definitions change across other dev-mode dependencies without version bumps and manually removing/re-adding the dependencies so the dependency scripts become globally viewable in the venv again.

I guess it may be more stable to end up with some "universal script launcher" platform external to the build environment if our usage is non-standard and functionality breaks across releases.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.