6 ms·

There was a time where I would have strongly related to this. Thankfully, now I've started using pipenv whenever possible and it basically just works(TM). I ho

• tomwphillips 8y ago
  Agreed. pipenv is wonderful.
• cecilpl2 8y ago
  Yes, pipenv is great and I am hopeful it gets adopted into the standard.
• TheCowboy 8y ago
  Seconding this recommendation of pipenv. https://github.com/pypa/pipenv https://github.com/pypa/pipenv It combines many features that people manage separately with virtualenv, pip, and any custom scripts. I think it reduces boilerplate and simplifies env management. It is still under active development, but I think it is stable enough to use for production. I think it's probably better for people learning Python to use too.
• yash1th 8y ago
  I believe pipenv still uses virtualenv instead of python's venv. Isn't that a drawback to use it?
  • blattimwind 8y ago
    Who would know?
    • yash1th 8y ago
      Well, if more and more packages in future move to python's offering venv. It would certainly be a problem that right now we are already facing
• marviel 8y ago
  Highly recommend pipenv.
• TomBombadildoze 8y ago
  pipenv doesn't solve any problems well, especially if you require multiple versions of Python, which is _always_ a problem if you're developing libraries. You still need something like pyenv to manage multiple versions of Python. If you're using pyenv, it's easy to do virtualenv with the pyenv-virtualenv plugin, at which point you don't need Pipenv because it doesn't solve anything (except locking, see blow) that you can't do with requirements files. Furthermore, if you're testing under multiple versions of Python, you'd use tox to manage your test environments anyway. _Further_ furthermore, they authors recommend _against_ use pipenv to manage dependencies for anything but development, so it's on you to have a copy of runtime dependencies isolated from Pipfile. And since you have to put your runtime requirements in setup.py anyway, there was never any way around the issue of duplicating requirements to begin with. The one thing Pipenv does that pip and requirements files can't is lock dependencies down the entire tree... except it's abominably slow at that because it has to download dependencies and walk the entire tree. There's a debate ongoing about using pip's cache to solve the problem but there's no end in sight. If you're really sensitive to having the entire dependency tree frozen to exact versions of you requirements, just `pip freeze` them occasionally. It's way less hassle. Packaging in Python is far better than it was a few years ago. There's still a lot to improve but pipenv shouldn't be part of the solution.
  • SmirkingRevenge 8y ago
    > _Further_ furthermore, they authors recommend _against_ use pipenv to manage dependencies for anything but development, so it's on you to have a copy of runtime dependencies isolated from Pipfile. I think the use-case is slightly different than that. Pipenv is a tool that enables reproducible builds for python app development and deployment. For example, many web apps, aren't going to be packaged up using setuptools, they are just going to be deployed somewhere (possibly containerized first). And with pipenv you can avoid the need to vendor all your dependancies to ensure reproducible builds. But its not a tool that solves problems for library packaging and distribution (on say pypi). You still have to use setup.py for that, and shouldn't be pinning your dependancies on exact package versions. But you can still use pipenv to manage your dev environment in those cases, and for reproducible dev environments.