pip-tools
pip-tools copied to clipboard
jazzband
Pipfile support
What's the problem this feature will solve?
Tell me if this is the wrong medium for this discussion, but I wanted to raise adding support for reading pipfiles directly as a source of dependencies.
Describe the solution you'd like
It would be nice to use the pipfile format for declaring different types of dependencies. All of the advantages of pipfiles are self-justified by its project, but in short could ease of the features that pip-compile already has, like development and "application" dependencies in one. It's another option in addition to requirements.in and setup.py.
Basically the idea is that I can continue to use requirements.txt as a lock file format to use directly with pip, but use Pipfile as the input file format, and get all the advantages of using pip-tools to begin with.
Alternative Solutions
Pipenv. I mean sure, it does work. It literally takes 15 minutes for me to add one dependency to a real environment I'm using, whereas pip-compile takes about 90 seconds. But pipenv is a little too prescriptive about lockfile format (I don't like it), and dependency resolution strategy (I don't like it), and requires everybody to use pipenv.
Additional context
I forked pip-tools and did it for my own project and it worked fine. I created a pull requests and added a lot more unit tests. To be frank the implementation is a little bit hacky (but possibly just as hacky as read the requirements file?), but implementation details can probably be discussed in the pull request:
https://github.com/jazzband/pip-tools/pull/1301
I think it would me much better to introduce pyproject.toml support first, as it is officially documented way of specifying your dependencies. Take a look at https://www.python.org/dev/peps/pep-0621/#dependencies-optional-dependencies
I'm glad to see that more PEPs are adding details to pyproject.toml. I didn't see that PEP until now.
I don't know that they're exclusive though. pip-compile already reads from setup.py and requirements.in. project.toml is analogous to (and better standardized than) setup.py. Similarly, I personally like the idea of using Pipfile for the same reason. It has some nice features like dev requirements, but mostly provides a standardized way of describing a requirements.in style declaration.
Adding pyproject.toml support is a great idea. I'd love to see support for both.
(Also, there's a pull request for an implementation of Pipfile sorry already 😉)
Sure, I just think that this is more future-proof than Pipfile. Pipenv will probably at some point move to pyproject.toml to be compatible both with this PEP and with other tools implementing it.
Do you have the sense that Pipfile is being replaced by pyproject.toml? I had the understanding that it was part of the long-term plan for the pip/python developers to support the Pipfile format. If Pipfile is going to disappear, then I agree that time shouldn't be wasted on a format destined to be deprecated. But if Pipfile is here to stay, will you eventually want to support it?
I would/will be more inclined to add support if pip itself ever does.
See also: pypa/pipfile#119
