3 ms·
pyproject.toml and pyproject.lock are analogous to Pipfile and Pipfile.lock Both attempt to replace requirements.txt, both have dependency resolvers and both a
by 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 agoYet 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 agoMy 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.