Future of pip-tools in a Pipenv world

[codingjoe]

Hi there,

I want to use this issue facilitate a discussion around pip-tools future in a Pipenv world.

Main question: Is there a legitimate reason to further maintain pip-tools?

I know that a lot of good people put good work into this tool and I have been using it myself for years. But I switched all my work to Pipenv now. At least to my knowledge it's features are a perfect superset of pip-tools features with the benefit of having the support by the Python foundation.

But that's really just my personal opinion, I'd really like to get an honest opinion from some of the core contributors like @nvie @vphilippon & @blueyed

What's your take on this question. Do you plan to further maintain pip-tools. If so why? And should we add a section to the readme to help distinguish between both tools?

Best!
-Joe

[blueyed]

I personally do not like pipenv, and prefer to use pip-tools therefore.

[stlehmann]

I like the idea of Pipenv. However, after using it a lot I switched back to pip and pip-tools. Mainly because of these reasons:

1. Pipenv is very slow mainly because of the hash functionality
2. The update procedure for packages is somehow obscure. I couldn't figure out how to update specific packages in a clean way
3. Inconsistencies when moving to different operating systems due to differing hashes

So I think pip together with pip-tools is a great and transparent way for package management and it should definetely stay.

[nvie]

I'd like to add that pip-tools is one of pipenv's dependencies, even though they've vendored it in and patched it — see https://github.com/pypa/pipenv/tree/master/pipenv/patched/piptools. The resolver engine inside pipenv is powered by pip-tools. I guess therefore that improvements to pip-tools could still end up trickling into pipenv.

[vphilippon]

I believe pip-tools still has a legitimate reason to be maintained as a dependency management solution for users using pip. Moving to pipenv is not something that can be done overnight in a large enterprise context with pipelines relying heavily on pip/pip-tools (i.e. my exact context). As long as pip is relevant in the python packaging ecosystem, I think that pip-tools will be relevant too.

Also, as @nvie said, pipenv currently relies on pip-tools' resolver. We've had back-and-forth contribution and discussion with pipenv core contributors such as @techalchemy too. Work done in pip-tools still benefits to pipenv right now.

As for mentioning pipenv in the readme and describing what's pip-tools role now, yeah that sounds like a good idea.

[techalchemy]

Hi there, pipenv maintainer here :) just to chime in briefly, pip-tools is amazing and will likely always be faster than pipenv. It occupies a space somewhere between pip and pipenv and it performs a core set of tasks in a pretty intuitive and straightforward way. We used to patch it a lot more heavily than we do, and improvements in pip-tools always land in pipenv (and we can likely open issues on some of the things we've changed to see if it makes any sense to merge those back in upstream).

Pip-tools is quite incredible and I'm pretty sure it has been the reference implementation and the jumping off point for most of the other resolution tooling. We have been kicking around some new libraries to handle true sat solving/backtracking but again, it will likely not compete with piptools and it still borrows heavily from many of the constructs here. I spend about 50% of my pipenv related code time messing around in piptools for various reasons. I would be quite devastated if y'all just ditched it !

[codingjoe]

Wow, thank you all for the great feedback. This was a really nice discussion and it helped me to understand a couple more details.
My suggestion now would be to make this information also available to users users. There is a other tools section in the readme file. Maybe we can extend that a bit, add a reference to Pipenv and write one or two crisp sentences that sum up this thread. Maybe we even add a link for people like me who are interested in the full story.

Sounds good?

[androiddrew]

I guess I am a little late to the discussion, but I am going to chime in anyway. When I discovered pip-tools I dropped considering Pipenv. Pipenv is popular, but that does not make it the right tool for my projects. Admittedly, I choose Foundation over Bootstrap, Vue over React, etc. so maybe I just don't like there being one game in town.

I developed a distaste for the Pipfile largely due to the fact that I make my applications installable via a setup.py file. It seemed like the Pipenv project was steering people to abandon this practice. Pip-tools gives me all the capabilities I need to both define a development environment, and create an installable application. For me it's the difference between a manual or an automatic transmission. I like my manual and maybe that makes me antiquated.

[techalchemy]

Pipenv definitely doesn’t discourage this. pipenv install -e .

[ztane]

I don't know why I hadn't seen pip-tools before; now that I've seen it today, I am going to use it instead of pipenv. I don't like how the pipenv handles for example virtual environments at all - the defaults are off and I am not interested in configuring tools to be sane with environment variables. That said, naturally pip-tools should grow towards the pipfile + lock approach.it just doesn't work for me

@androiddrew I think Pipfile is saner than that... I too would prefer setup.py - but unfortunately with the current apps we have we are using lots of 3rd party libraries with badly bounded requirements and we cannot patch all of them - especially the older released versions that we depend on.

[cjerdonek]

Just to chime in, I'm a happy long-time pip-tools user. Probably because of pip-tools, I've never felt a need to try pipenv. pip + pip-tools does what I need.

[rsyring]

FWIW, I led the adoption of Pipenv at my company but am now looking at different options. We have encountered a number of bugs/obscurities in Pipenv that make the tool unreliable to use. I like pipenv and hope it matures over time, but until then, I'm going to be looking for alternatives and this project is top of my list (along with Poetry).

Also, @nvie given my experience above and the many open issues on the pipenv repo, you may want to re-consider the recommendation at the top of this post (this is actually what I came to post an issue about).

[nvie]

Thanks for pinging me about this @rsyring — I've just updated the recommendation in that post! Cheers!

[cjerdonek]

By the way, @nvie, as a pip maintainer and fan and user of pip-tools, I'd love to know if there is any low-hanging fruit in terms of possible changes to pip that could help make pip-tools more robust in its reliance on pip.

[rsyring]

@nvie that new article you linked to was very helpful. Thank you!

[pauloxnet]

It seems that pipenv is not maintained anymore
pypa/pipenv#4058

[auvipy]

poetry <3

[codingjoe]

@auvipy aren't you even a PyPa member 🤣 poor Pipenv, I didn't know Python has become the new nodeJS and I need to switch package managers every other month now 🤷‍♂

[auvipy]

pipenv wasnt my choice ever. i usually use pip. but pyenv+poetry+pipx seems to be my next combo.

[hlongmore]

It seems that pipenv is not maintained anymore
pypa/pipenv#4058

For those coming along after, there was a lack of activity for a few months, but https://github.com/pypa/pipenv/graphs/code-frequency shows that it picked up again in 2020.

[codingjoe]

I will close the issue for now, since there is no action required based on this thread. However, feel free to post further comments or updates about this topic and any ongoing developments.