Generate `requirements.txt` from `Pipfile` rather than `Pipfile.lock`

[ypsah]

Hi, at the moment pipenv requirements only has support for generating a requirements.txt from Pipfile.lock. I would like pipenv requirements to have an option to use Pipfile as its source instead.

My rationale is that packages like setuptools are adding support to define a package's install_requires from a requirements.txt file and strictly pinned dependencies (package==version) are less suitable for python libraries than loosely pinned ones (package, package>=version, ...). [1]

[1] strictly pinned dependencies might be acceptable for applications, but they create too many version conflicts for libraries.

Is your feature request related to a problem? Please describe.

I would like to be able to use pyproject.toml + pipenv requirements + setuptools to package my python libraries using the following workflow:

• pyproject.toml defines dependencies as dynamic and instructs setuptools to infer them from a requirements.txt file;
• pipenv requirements --lock=false > requirements.txt is used to generated said requirements.txt.

pipenv requirements does not support --lock=false at the moment and without it, the version pins that it generates are too strict for python libraries to use as their install_requires.

Describe the solution you'd like

I think adding a --lock=[true/false] to the pipenv requirements command could be a nice option, with --lock=true as the default for backwards-compatibility purposes.

Describe alternatives you've considered

1. Implementing my own Pipfile parsing / requirements.txt generation logic:

import toml
from pathlib import Path

packages = toml.load(Path("Pipfile"))["packages"]
for name, specification in packages.items():
    match specification:
        case str() if specification.startswith(("<", ">", "~=", "!=")):
            print(f"{name}{specification}")
        case "*":
            print(name)
        case _:
            raise NotImplementedError(
                f"Unsupported dependency specification: {specification}"
            )

This is error-prone, and as can be seen above, a lot more work would need to go into this to support the many dependency specification formats that Pipfile supports.

2. Add support for Pipfile as a dynamic source of dependencies in setuptools: I expect this to happen eventually once pip gains support for installing packages from Pipfiles, but this seems unlikely to happen on the short term;

3. Creating a setuptools plugin to use Pipfile as a dependency source: I believe this is what setuptools-pipfile tries to achieve. Downside is that this only works with setuptools, setuptools-pipfile is still in "beta" as I write this issue, and I would have to audit+trust the code base to use it in my projects. [2]

4. Use an external implementation of exactly this feature: pipenv-to-requirements seems like an obvious candidate here. The third-party argument (need to audit & trust) applies here again.

[2] To its credit I think setuptools-pipfile is an excellent workaround at the moment, and I recommend people check it out if they build their projects using setuptools.

[matteius]

The requirements generated from the Pipfile would not be a complete requireiments file the way the one generated from the Pipfile.lock is.

[ypsah]

I understand this, but it would still be a valid requirements.txt. I think it would make for a better source of install_requires for python libraries than the one which is generated at the moment, as libraries need to have more flexible requirements than applications to be installed next to other projects.

[oz123]

Maybe this can be an option? WITH CAPITAL WARNING?

$ pipenv requirements --from-pipfile
WARNING: this is dangerous ....
....

[ypsah]

Yes, sure.

I don't mind the implementation details, especially when setuptools-pipfile solves the issue for me at the moment and I've done the work of auditing the code (still early to trust future updates).

I see value in the feature being available within pipenv itself, but I would understand if you do not consider it a priority.

I for one am unlikely to contribute this feature into pipenv right now, so feel free to close the issue.

[matteius]

I think we can consider it. Top priority right now is fixing bugs because we have done some new features and updates during Hacktoberfest that need some edge case cleanup. I'll give this more thought though.