setup-python: pip install on latest ubuntu fails with error
Description: github actions for python 3.8 fails with the following error:
ERROR: Invalid requirement: 'Warning: The lock flag' (from line 2 of requirements.txt)
Action version:
runs-on: ubuntu-latest (python-version: [ '3.8' ])
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
Platform:
- Ubuntu)
- macOS
- Windows
Runner type:
- Hosted
- Self-hosted
Tools version:
Repro steps:
Create a repo with Pipfile, add dependencies and lock the Pipfile.
run:
python -m pip install --upgrade pip setuptools pipenv virtualenv PyYAML flake8 pylint nose coverage
pipenv --python '3.8' lock -r > requirements.txt
pip install -r requirements.txt
Expected behavior: pip should install all required packages
Actual behavior: pip fails with thee following error:
ERROR: Invalid requirement: 'Warning: The lock flag' (from line 2 of requirements.txt)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 7
- Comments: 15 (3 by maintainers)
Commits related to this issue
- fix: install dependencies to the system directly from pipenv This will solve this problem for now https://github.com/actions/setup-python/issues/398 — committed to dignio/generate-manifest by bjarneo 2 years ago
- fix: install dependencies to the system directly from pipenv This will solve this problem for now https://github.com/actions/setup-python/issues/398 — committed to dignio/generate-manifest by bjarneo 2 years ago
- fix: install dependencies to the system directly from pipenv This will solve this problem for now https://github.com/actions/setup-python/issues/398 fix: install dependencies to the system directly ... — committed to dignio/generate-manifest by bjarneo 2 years ago
- Add workaround for bug in pipenv 2022.3.24 https://github.com/actions/setup-python/issues/398 — committed to Pocket/data-flows by mmiermans 2 years ago
- Fix deployment (#65) * Get ECR repository from Terraform-Modules * Remove unused function from DataFlowsCodePipeline * Workaround Fn bug in cdktf 0.9.0 See https://github.com/hashicorp/terra... — committed to Pocket/data-flows by mmiermans 2 years ago
A quick fix is sticking to the immediately previous version
Update:
You should consider using
pipenvto install dependencies and not convert them torequirements.txtand install usingpip(because this).A good way of doing so can be
pipenv install --systemif you don’t want to change how you run commands inside your environment.@ianyoung There was a deprecation warning around
install -rfor a number of releases, please use the newerpipenv requirementscommand.@singhpratyush
The issue you linked to is from 2019, I think a lot has changed since then. Furthermore you are doing a
pipenv lock -rto generate your requirements which goes through the same locking and resolution process that used to have timeout issues, in order to generate a requirements file. If you already have the lock file you can speed this up by simply installing from it and skipping lock in your CI altogether, which would be preferable for security reasons. Simply runpipenv syncorpipenv install --deployto install the dependencies from your lock file using pipenv and then you can uninstall pipenv just the same as you are in that article to reduce space.It is less about compatibility and more about security. If you are generating your lock file on every CI run and installing requirements from that without hash checking, then you aren’t verifying that the packages you install in the CI today match the exact versions that you installed yesterday. The version numbers will match, but the package contents could have changed either because it resolved to a different pypi server (DNS poisoning or otherwise), package confusion attack against a private package in the public pypi, or general bad actor published a different version of a package that was not pinned and that gets pulled in automatically. There are many ways this could happen and that is what the hash checking helps prevent against, but it doesn’t provide protection if the CI regenerates the hashes every build, or discards them during the install phase.