Open ypsah opened 1 year ago
The requirements generated from the Pipfile would not be a complete requireiments file the way the one generated from the Pipfile.lock is.
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.
Maybe this can be an option? WITH CAPITAL WARNING?
$ pipenv requirements --from-pipfile
WARNING: this is dangerous ....
....
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.
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.
Hi, at the moment
pipenv requirements
only has support for generating arequirements.txt
fromPipfile.lock
. I would likepipenv requirements
to have an option to usePipfile
as its source instead.My rationale is that packages like
setuptools
are adding support to define a package'sinstall_requires
from arequirements.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 theirinstall_requires
.Describe the solution you'd like
I think adding a
--lock=[true/false]
to thepipenv requirements
command could be a nice option, with--lock=true
as the default for backwards-compatibility purposes.Describe alternatives you've considered
Pipfile
parsing /requirements.txt
generation logic: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 usingsetuptools
.