fix: Remove outdated Pipenv requirements flag

[jfgordon2]

Removes use of the now-removed flag --keep-outdated on pipenv lock. See pipenv 2023.7.9 release notes.

Rather than re-generating or potentially updating a user's Pipenv.lock file, it'll go straight into trying to build the requirements file.

The pre-existing behavior was that if the Pipfile.lock file was missing, that the plugin will generate one. Since this is likely undesireable, added a warning log message pointing a user to the Pipenv documenation on how to address it.

Also updates github-actions test matrix to include the before/after of this pipenv behavior change.

Closes: #779

[rwestergren]

Thanks for fixing this - I starting running into it today.

I forked your branch and ran the Validate GH action: https://github.com/rwestergren/serverless-python-requirements/actions/runs/5579741623/jobs/10195698425

Looks like the prettier check will fail.

[jfgordon2]

Thanks for fixing this - I starting running into it today.

I forked your branch and ran the Validate GH action: https://github.com/rwestergren/serverless-python-requirements/actions/runs/5579741623/jobs/10195698425

Looks like the prettier check will fail.

Ah! Good catch! I ran the prettify:updated command and pushed. Thanks @rwestergren!

[jfgordon2]

@rwestergren I ran the validate workflow in my account to fix the remaining issues on commitlint, and things are now passing. I appreciate the heads-up.

[pgrzesik]

Thanks a lot @jfgordon2 and sorry for not looking into it sooner. I have one question before merging. Do you think we shouldn't keep support for the older pipenv versions that still have the --keep-outdated flag? This is potentially a breaking change, even if the behavior might not be desirable by most people. If we drop the flag altogether, it would be great to update the docs and release it as a part of a new major version of the plugin

[jfgordon2]

@pgrzesik I appreciate you taking a look!

My understanding is that pipenv lock --keep-outdated simply generated a Pipfile.lock file based on what's installed in the virtual environment but without updating to the latest versions allowed by the Pipfile definitions. To even have such an environment setup, the dev will have needed to have run pipenv sync which depends on the existence of the Pipenv.lock file or pipenv install which generates a Pipfile.lock or updates an existing one.

To me, it seems like the pipenv lock --keep-outdated is a wasted step on any version where pipenv requirements exists, and it feels like it was only kept here because the old command pattern used to be pipenv lock --requirements --keep-outdated in order to generate the requirements.txt file, and somebody was adhering to the Chesterton's fence principle in implementing the new way.

In this implementation, I'm following the Pipenv project's expectations that there will be a Pipfile.lock existing alongside the Pipfile, though added a warning just in case we don't see the expected files, and pointing a user to the Pipenv docs. We will see two potential benefits:

1. The current pipenv lock --keep-outdated command outputs the below error, indicating to me that we could potentially have been packaging slightly different versions than what is described by the lock file. Hopefully this change makes packaging more predictable.

"The flag --keep-outdated has been deprecated for removal. The flag does not respect package resolver results and leads to inconsistent lock files. Consider using the new pipenv upgrade command to selectively upgrade packages"

2. Removing the pipenv lock --keep-outdated operation prior to running pipenv requirements will also increase the speed of packaging with the same or possibly more predictable results.

The pipenv requirements command was implemented in v2022.4.8, and this file branches behavior on versions <=2022.8.5, so perhaps we're already supporting the older pipenv versions, anyway?

[pgrzesik]

Thanks for clarification and your work on this one. 🙇