Fix lock -r warning being logged to stdout instead of stderr

[tomarad]

The issue

In #5069, a deprecation message was added when pipenv lock -r is run.
The warning message is written to stdout instead of stderr, breaking scripts that run commands like pipenv lock -r > requirements.txt.

The fix

This PR directs the warning message to stderr instead of stdout.
I also de-dented the message to make it look nicer:

Old (notice the newline at the top):

            Warning: The lock flag -r/--requirements will be deprecated in a future version
            of pipenv in favor of the new requirements command. For more info see
            https://pipenv.pypa.io/en/latest/advanced/#generating-a-requirements-txt
            NOTE: the requirements command parses Pipfile.lock directly without performing any
            locking operations. Updating packages should be done by running pipenv lock

New:

Warning: The lock flag -r/--requirements will be deprecated in a future version
of pipenv in favor of the new requirements command. For more info see
https://pipenv.pypa.io/en/latest/advanced/#generating-a-requirements-txt
NOTE: the requirements command parses Pipfile.lock directly without performing any
locking operations. Updating packages should be done by running pipenv lock.

[matteius]

Thanks @tomarad -- would you add a bugfix news fragment for this and reference the PR number (unless there is an issue report)?

[tomarad]

Done @matteius.

[jaredthecoder]

Slightly annoying, this bit me today here - actions/setup-python#398. If anyone sees this, be sure your pipenv in your actions is completely up to date as pip install pipenv as of 30 minutes ago will still produce this message to stdout, breaking your CI pipeline if you then install the locked requirements with pip.

Or even better use something like pipenv requirements -i https://pypi.org/simple > requirements.txt from https://pipenv.pypa.io/en/latest/advanced/#generating-a-requirements-txt

[ImreC]

Wow, should have realized this. Apologies and thanks for the fix

[matteius]

@ImreC If it makes you feel better I've done the same thing in a recent release in a refactor of a print statement.

[ImreC]

@matteius thanks! It is an easy thing to miss I guess. @tomarad if you add a newline in the newsfile, the checks will pass.

[alex9311]

hey all, I'm still getting this issue while using AWS CDK. It uses pipenv lock -r to generate a requirements file.
https://github.com/aws/aws-cdk/blob/c3c4a97e65071fcab35212be82dea7b29454786f/packages/%40aws-cdk/aws-lambda-python/lib/packaging.ts#L40

In my logs I can see that pipenv-2022.4.30 is being installed. Does this fix need to be part of a new pipenv release? It seems 4.30 is the latest version which I assume doesn't include this fix

[guyc]

The release notes show that this PR (#5091) did not make it into the most recent release (v2022.4.30).

This issue is currently breaking our CI/CD deployments which use the serverless-python-requirements plugin.

[matteius]

@guyc I just tagged a new release for this issue. 2022.5.2

[rafsanbhuiyan12]

1. Frist uninstall pipenv: 'pip uninstall pipenv` OR 'brew uninstall pipenv' OR 'sudo uninstall pipenv'
2. Second install pipenv==2022.5.2: sudo pip install pipenv==2022.5.2

pipenv: 2022.5.2 works great!! ⚡️🚀🤘😃