-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: pipenv should have a native way to generate requirements.txt directly from the lockfile #4959
Comments
@ImreC I am wondering if what you need is actually the |
I am not sure I follow the argument here that the strict package dependencies being included lead to dependency mismatches, if you are generating the requirements.txt from the Here is an experiment. Pipfile:
Which is basically identical to the one generated by |
Hi @matteius, thanks for responding! I can give an example of where
This leads to the following requirements.txt
which pins idna at 3.3, but I think requests depends on idna <3 so this errors out when you try to install with normal pip from requirements.txt (or at least I confirmed this when building with AWS SAM). Running |
I just went through the pipenv repo real quick and from what I can tell (in 5 minutes) the intended behavior of |
Yes it still includes the Pipfile in the chain, but if it doesn't differ from the lock file, it will not update anything. What version of
Yes but if you haven't modified the Pipfile, there will be nothing to update to the lockfile. Since you didn't include the lock file in your example, it would have to be generated from the Pipfile you provided.
Your project is using pipenv, therefore it has a Pipfile, you can generate a requirements.txt from the It may be possible to have a command that generates the package requirements from just the lockfile, but I am not sure I really understand the use case and it feels a little bit like duplicating existing functionality (that currently also looks at the Pipfile) in order to get the same result.
This just puts what you have installed in your virtualenv into requirements.txt not looking at the Pipfile or the lock file.
That means you have idna 3.3 installed somehow when you really depend on |
@ImreC Another thing about your latest example Pipfile is you have |
I moved |
@matteius I tried to install the generated requirements.txt from This was the output of
but I see that the idna requirement that is printed out is indeed the requirement for Python 2, so I don't really know why this was printed out. On top of that I am currently unable to reproduce my original error even though I was able to this morning. I am genuinely confused by this. I am using pipenv version 2022.1.8. Also, I know what I just want to stress that I am not pushing to put something into pipenv that has no value. If May I suggest we update the documentation here https://pipenv.pypa.io/en/latest/basics/#pipfile-lock-security-features to also mention the Thanks for taking the time to look into this. Really appreciate it! |
I know, I was just trying to see if there is an existing solution that would work for you now, rather than wait for something to get accepted and published in a new release. There might be value in having a command that does such a thing when a Pipfile is lacking or has been changed and the history is gone. I just want to be careful before supporting too many new commands, if they are truly required. I am hoping others will weigh in on their uses cases, and also I'll say what I said to the developer that wrote the new |
I have a bit of a busy period, but plan to revisit this in a couple of weeks. Also will look into creating a PR at that time. If people are reading this and feel this is a useful addition, please add a thumbs up. |
I have created a PR for this. Would appreciate a look. |
This feature has been merged. |
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
Switch from using `pipenv sync --system` to using the requirements file generated from `pipenv requirements`. The `pipenv sync --system` command (added in #1993) does not work in newer versions of pipenv. It uses the python version of the system rather than the one specified by the --python flag. The `pipenv requirements` command has been added that only pulls from the Pipfile.lock file (pypa/pipenv#4959, pypa/pipenv#5200), and fixed to only dump out requirements for the appropriate system (see pypa/pipenv#5092).
When you just run pipenv install [package] on your project the version in the Pipfile is not pinned, but the lockfile contains the installed package version. Unfortunately not all tooling around Python supports Pipfiles, which means that you very often need to generate a requirements.txt file based on your Pipfile.lock. I think all approaches for this are well described here: #3493, but for simplicity I will outline them below:
pipenv lock -r
. Why this does not work is that it runspipenv lock
, which generates a new lockfile and then generates the requirements. This leads to problematic cases if you want to keep the requirements exactly the same.pipenv run pip freeze > requirements.txt
(potentially withpipenv sync
before that to make sure that all the packages from Pipfile.lock` are installed). Why this is problematic is because running pip freeze very often leads to too many strict package dependencies being included which leads to dependency mismatches, rendering the whole file unusable.jq
or some similar tool that literally parse the lockfile and then output a requirements.txtI think the problem with option 1 and 2 is that they both do too much. Option 3 is closest to what most people need, but introduces a new dependency on
jq
which is also annoying to enforce across a larger group of developers with multiple environments. Which lead to that I am now including a simple python file containing this in almost every repo:I feel that this is so mindbogglingly simple that it should be included somewhere in the pipenv package. My proposition is to include a command
pipenv requirements
which reads the Pipfile.lock json file and outputs a requirements.txt based on the default key. Adding--dev
as an option also adds the requirements from the develop key. No locking, no syncing, no pip freezing. Just this.I am not only asking for this, but also happy to take some time to implement/maintain this if other people support this idea.
Overall, I think pipenv is a vital tool in the Python ecosystem and will continue to use it in any case. Thanks for the work that went into this so far! I think adding this seemingly trivial extra command would resolve some confusion around the requirements.txt (f.e. #4731) and therefore would be a relatively low effort high value feature for pipenv.
The text was updated successfully, but these errors were encountered: