We have moved our dependency management from pipenv to poetry and hasn’t been more happier than now working with and publish Python modules.<p>Now we use pyenv with poetry to run all our projects in Python with venv in project instead of decided by poetry default settings. We changed the settings with:<p><pre><code> poetry config settings.virtualenvs.in-project true
</code></pre>
After this in hgignore or gitignore added .venv folder.<p>Now everything is the way we wanted, with Pipenv many times faced issues that the project worked with requirements.txt but not in Pipenv. Didn’t have this issue moving to poetry yet.<p>Also with emacs support and automated deployment tools the predictability of poetry made our team easy to work with and publish Python application modules.
The recommended installation method still doesn't work without manual intervention. For the reference, I use WSL with the latest Ubuntu LTS version.<p>- I tried using the recommended installation method of<p><pre><code> curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python
</code></pre>
Didn't work. I don't have python installed, just python3. Fair enough.<p>- Using the above method, but replacing `| python` with `| python3`: The installation works. But trying to invoke poetry gives this error:<p><pre><code> /usr/bin/env: ‘python’: No such file or directory
</code></pre>
Turns out poetry executable is calling python in the shebang.<p>- Manually changed shebang in `$HOME/.poetry/bin/poetry` to `#!/usr/bin/env python3`: Now poetry runs successfully.<p>I mean, it works, but it is fragile (shebang probably needs to be manually reset at every update), not beginner-friendly, and not ergonomic. Installing using pip3 has the same issue. In comparison, pipenv is much easier to install. I was hoping this issue would not be present for poetry v1.0, but unfortunately it is.
Even putting aside it's approach to dependency management, Poetry has a fond place in my heart for making it so much easier to publish to PyPI.<p>If poetry did nothing but simply the process of publishing and updating python packages, it would still be an amazing tool.
While I'm excited that Poetry hit 1.0, I'm actually more excited about the fact more devs were added to the maintenance team and that it transitioned to a project namespace. Sébastien was previously the sole dev with commit access so I'm hopeful this gives the project a much healthier future.
I've been watching poetry for the last couple years, hoping that it is THE replacement to the virtualenv/virtualenvwrapper/pyenv workflow.<p>pipenv never felt quite right. poetry has felt really close.<p>I'd love to know if anyone has made this jump and their experience.
hopefully v1.0 now means it's pretty stable. using poetry so far has been painful, the gains you got with the improved dependency resolution were unfortunately somewhat impacted by crazy annoying bugs, like `poetry shell` not actually activating the virtual environment [0]<p>[0] <a href="https://github.com/python-poetry/poetry/issues/571" rel="nofollow">https://github.com/python-poetry/poetry/issues/571</a><p>edit: gah, still hitting baffling errors:<p><pre><code> $ poetry env use /usr/local/bin/python3
[NoCompatiblePythonVersionFound]
The specified Python version (3.7) is not
supported by the project (^3.7).
Please choose a compatible version or loosen the python constraint specified in the pyproject.toml file.
$ poetry env use /usr/local/bin/python3
[NoCompatiblePythonVersionFound]
The specified Python version (3.7) is not
supported by the project (>=3.7).
Please choose a compatible version or loosen the python constraint specified in the pyproject.toml file.
</code></pre>
v1.0.0 generally seems to work smoother though
For whatever reason, I've never understood the point or actual benefit of virtualenvs.<p>Having lived more in the JS ecosystem for the last several years, my ideal workflow would be a copy of how the Yarn package manager works:<p>- Top-level dependencies defined in an editable metadata file<p>- Transitive dependencies with hashes generated based on the calculated dependency tree<p>- All dependencies installed locally to the project, in the equivalent of a `node_modules` folder<p>- All package tarballs / wheels / etc cached locally and committed in an "offline mirror" folder for easy and consistent installation<p>- Attempting to reinstall packages when they already are installed in that folder should be an almost instantaneous no-op<p>PEP-582 (adding standard handling for a "__pypackages__" folder) appears to be the equivalent of `node_modules` that I've wanted, but tools don't seem to support it yet. I'd looked through several Python packaging tools over the last year, but none of them seemed to support it yet (including Poetry [0]).<p>The only tool that I can find that really supports PEP-582 atm is `pythonloc` [1], which is really just a wrapper around `python` and pip` that adds that folder to the path. Using that and `pip-tools`, I was able to mostly cobble together a workflow that mimics the one I want. I wrote a `requirements.in` file with my main deps, generated a `requirements.txt` with the pinned versions and hashes with `pip-compile`, was able to download and cache them using `pip`, and installed them locally with `piploc`.<p>Admittedly, I've only tried this out once a few weeks ago on an experimental task, but it seemed to work out sufficiently, and I intend to implement that workflow on several of our Python services in the near future.<p>If anyone's got suggestions on better / alternate approaches, I'd be interested.<p>[0] <a href="https://github.com/python-poetry/poetry/issues/872" rel="nofollow">https://github.com/python-poetry/poetry/issues/872</a><p>[1] <a href="https://github.com/cs01/pythonloc" rel="nofollow">https://github.com/cs01/pythonloc</a><p>[2] <a href="https://github.com/jazzband/pip-tools" rel="nofollow">https://github.com/jazzband/pip-tools</a>
Does anyone know if the situation with using `poetry` with `pyenv` has gotten any better? I like poetry's approach, but I had a very difficult time getting it to play nice with my system last time I tried.
What's the advantage of using poetry compare to vendorize your dependencies and check in the whl files (which can be manylinux binary) into your version management system?
I thought the billions ways to sort out dependencies and environments Python were its messiest part. I've been using a custom little batch script on windows to streamline that a bit as I mainly use python for small utilities as opposed to big projects - <a href="https://gist.github.com/leoncvlt/10e67d9415e61eff0f5010ef6fec51d8#file-evenvo-bat-L33" rel="nofollow">https://gist.github.com/leoncvlt/10e67d9415e61eff0f5010ef6fe...</a> - but interested in giving this a spin!
Big discussion about project 4 months ago:<p><a href="https://news.ycombinator.com/item?id=20672436" rel="nofollow">https://news.ycombinator.com/item?id=20672436</a>
Just to note, dev dependencies in Poetry is still rather flaky vis-à-vis projects forever in pre-release mode e.g. Black. Consider sticking with Pipenv if you have heavy dev dependencies requirements.
Messing around with major/minor Python version compatibility and dependency conflicts has always been my least favorite part of Python. A tool like this is much appreciated!
It's not clear from the current title but Poetry v1.0.0 was just released: <a href="https://github.com/python-poetry/poetry/releases/tag/1.0.0" rel="nofollow">https://github.com/python-poetry/poetry/releases/tag/1.0.0</a>