3 ms·

A lot of people seem to run into bugs and some hit a brick wall when they report them: https://www.reddit.com/r/Python/comments/8elkqe/pipenv_a_guide_to_the_ne

A lot of people seem to run into bugs and some hit a brick wall when they report them: https://www.reddit.com/r/Python/comments/8elkqe/pipenv_a_guide_to_the_new_python_packaging_tool/ https://www.reddit.com/r/Python/comments/8elkqe/pipenv_a_gui... Personally I think poetry doesn't get enough visibility. It's not as hyped as pipenv but it feels a bit nicer: https://poetry.eustace.io/ https://poetry.eustace.io/

jsmeaton 8y ago
It really serves a different audience/purpose. Poetry replaces setup.py which is mostly used for building libraries. You still need to create your own virtualenv. Pipenv replaces requirements.txt and handles the virtualenv for you. It can’t be used for packaging libs, but it’s primary purpose is to make developing on apps easier. Lore seems to be much closer to pipenv than poetry.
- crdoconnor 8y ago
  pyproject.toml and pyproject.lock are analogous to Pipfile and Pipfile.lock Both attempt to replace requirements.txt, both have dependency resolvers and both are workflow tools.
  - jsmeaton 8y ago
    Yet poetry does not manage the virtualenv for you which is what these other tools do. I think poetry would find a lot more love outside of packaging where people are now using pipenv if it managed the virtualenv too. The integration pipenv has with pyenv is also very nice. Many people want less tools, which is the primary reason pipenv took off IMO. Creating and activating virtualenvs? mkvirtualenv? Minor python version changes and the venv is toast? Different ways of structuring requirements files? It’s a mess for juniors especially. People that are packaging libs probably aren’t having the same difficulty with virtualenvs that junior devs are when starting at a company deving on new code bases, learning new processes and tools. But packaging and releasing python libs is challenging, so tooling to help with that is awesome. A single tool that can do packaging, dependency management, and venv management would be embraced. If poetry doesn’t add venv management, then pipenv should add packaging management.
    - crdoconnor 8y ago
      >Yet poetry does not manage the virtualenv for you which is what these other tools do. That's not correct: https://poetry.eustace.io/docs/basic-usage/#poetry-and-virtualenvs https://poetry.eustace.io/docs/basic-usage/#poetry-and-virtu... >A single tool that can do packaging, dependency management, and venv management would be embraced. It does all of those.
      - jsmeaton 8y ago
        My apologies! I checked the wrong place in the docs before commenting, you are right. Can you direct it to use a python other than the one linked to poetry? I don’t have CLI access at the moment.
SmirkingRevenge 8y ago
Poetry looks nice - that dev has authored some other really nice looking libs. After skimming the docs and tinkering with poetry a bit, I'm not sure what my workflow with it would be for containerized python apps, though - where you generally don't want virtual environments at all. Pipenv handles that case pretty well. I might reach for it though if I were developing open-source libraries that would be distributed on pypi
- crdoconnor 8y ago
  You don't need to but there's also no harm in creating a virtualenv in a container.

jsmeaton 8y ago

It really serves a different audience/purpose. Poetry replaces setup.py which is mostly used for building libraries. You still need to create your own virtualenv. Pipenv replaces requirements.txt and handles the virtualenv for you. It can’t be used for packaging libs, but it’s primary purpose is to make developing on apps easier. Lore seems to be much closer to pipenv than poetry.

crdoconnor 8y ago
pyproject.toml and pyproject.lock are analogous to Pipfile and Pipfile.lock Both attempt to replace requirements.txt, both have dependency resolvers and both are workflow tools.
- jsmeaton 8y ago
  Yet poetry does not manage the virtualenv for you which is what these other tools do. I think poetry would find a lot more love outside of packaging where people are now using pipenv if it managed the virtualenv too. The integration pipenv has with pyenv is also very nice. Many people want less tools, which is the primary reason pipenv took off IMO. Creating and activating virtualenvs? mkvirtualenv? Minor python version changes and the venv is toast? Different ways of structuring requirements files? It’s a mess for juniors especially. People that are packaging libs probably aren’t having the same difficulty with virtualenvs that junior devs are when starting at a company deving on new code bases, learning new processes and tools. But packaging and releasing python libs is challenging, so tooling to help with that is awesome. A single tool that can do packaging, dependency management, and venv management would be embraced. If poetry doesn’t add venv management, then pipenv should add packaging management.
  - crdoconnor 8y ago
    >Yet poetry does not manage the virtualenv for you which is what these other tools do. That's not correct: https://poetry.eustace.io/docs/basic-usage/#poetry-and-virtualenvs https://poetry.eustace.io/docs/basic-usage/#poetry-and-virtu... >A single tool that can do packaging, dependency management, and venv management would be embraced. It does all of those.
    - jsmeaton 8y ago
      My apologies! I checked the wrong place in the docs before commenting, you are right. Can you direct it to use a python other than the one linked to poetry? I don’t have CLI access at the moment.

SmirkingRevenge 8y ago

Poetry looks nice - that dev has authored some other really nice looking libs. After skimming the docs and tinkering with poetry a bit, I'm not sure what my workflow with it would be for containerized python apps, though - where you generally don't want virtual environments at all. Pipenv handles that case pretty well. I might reach for it though if I were developing open-source libraries that would be distributed on pypi

crdoconnor 8y ago
You don't need to but there's also no harm in creating a virtualenv in a container.