Generate `requirements.txt` from `Pipfile` rather than `Pipfile.lock`
See original GitHub issueHi, 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
definesdependencies
asdynamic
and instructssetuptools
to infer them from arequirements.txt
file;pipenv requirements --lock=false > requirements.txt
is used to generated saidrequirements.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
- 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.
-
Add support for
Pipfile
as a dynamic source ofdependencies
insetuptools
: I expect this to happen eventually oncepip
gains support for installing packages fromPipfile
s, but this seems unlikely to happen on the short term; -
Creating a
setuptools
plugin to usePipfile
as a dependency source: I believe this is whatsetuptools-pipfile
tries to achieve. Downside is that this only works withsetuptools
,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] -
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
.
Issue Analytics
- State:
- Created 10 months ago
- Comments:5
Top GitHub Comments
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.
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.