
Poetry – Dependency Management for Python – v1.0 - devj
https://github.com/python-poetry/poetry/releases/tag/1.0.0
======
dragonsh
We have moved our dependency management from pipenv to poetry and hasn’t been
more happier than now working with and publish Python modules.

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:

    
    
      poetry config settings.virtualenvs.in-project true
    

After this in hgignore or gitignore added .venv folder.

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.

Also with emacs support and automated deployment tools the predictability of
poetry made our team easy to work with and publish Python application modules.

~~~
ageofwant
Nice. I do however much prefer keeping the venv out of the source tree where
they do not interfere with `tree` and `grep` and whatnot. I'm curios what
benefit you see with having the venv cluttering the work-space ?

~~~
wp381640
It took me a while to be convinced to switch to in-folder venv but the
benefits are

* VS Code configuration so much easier as you can point to the correct env using a relative path in settings.json and check that in

* Predictable paths to execute tasks / build

* No outside of development tree vens that you forget to clean up or forget to deactivate

* No different to node_modules, .git or similar when it comes to "polluting" the local project tree as you can .gitignore it

~~~
BerislavLopac
> as you can .gitignore it

As well as ignore config in codecov, black, flake8, mypy and so on...

------
smnrchrds
The recommended installation method still doesn't work without manual
intervention. For the reference, I use WSL with the latest Ubuntu LTS version.

\- I tried using the recommended installation method of

    
    
        curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python
    

Didn't work. I don't have python installed, just python3. Fair enough.

\- Using the above method, but replacing `| python` with `| python3`: The
installation works. But trying to invoke poetry gives this error:

    
    
        /usr/bin/env: ‘python’: No such file or directory
    

Turns out poetry executable is calling python in the shebang.

\- Manually changed shebang in `$HOME/.poetry/bin/poetry` to `#!/usr/bin/env
python3`: Now poetry runs successfully.

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.

~~~
yellowapple
Curious what's stopping you from symlinking python3 to python? In fact, I'm
surprised the package manager didn't already do that (I thought it did for
Debian and its derivatives, including Ubuntu). Does WSL throw a wrench in that
or something?

~~~
rat87
Because python link/binary is python 2, which you might also have installed

Being able to rely on python being python 2 and python3 being python 3 is
pretty useful

------
Townley
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.

If poetry did nothing but simply the process of publishing and updating python
packages, it would still be an amazing tool.

~~~
hiccuphippo
I've read of another project for publishing to PyPI called flit. Anyone knows
how they compare to each other?

~~~
brettcannon
Poetry tries to help you manage your whole project while flit is just for
building your library (and optionally uploading; you can always use twine to
do the upload). It's all-in-one versus one-job-one-tool.

------
Caligatio
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.

~~~
oefrha
The project org has two (public) members and the second highest contributor
has 10 commits with <600 lines. It would inspire more confidence if the
project is transferred (invited) to pypa some day.

------
dhruvkar
I've been watching poetry for the last couple years, hoping that it is THE
replacement to the virtualenv/virtualenvwrapper/pyenv workflow.

pipenv never felt quite right. poetry has felt really close.

I'd love to know if anyone has made this jump and their experience.

~~~
siddboots
Same here. I got really excited by pipenv, but every single time I've tried
it, it takes 10+ minutes to determine the dependencies and build a lock file
(see issue 2284 [1]). It just makes it un-usable for a lot of my use-cases,
e.g. setting up a clean environment for exploratory data analysis. Does anyone
know if poetry improves in this area?

[1]
[https://github.com/pypa/pipenv/issues/2284](https://github.com/pypa/pipenv/issues/2284)

~~~
hobofan
(See my other comment)

Yes, I haven't encountered any of the slowness in dependency resolution that
Pipenv has with Poetry. It does still feel a bit slow compared to package
managers from other languages, but not in a buggy way, so I would attribute it
to not being that optimized yet.

------
guitarbill
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]

[0] [https://github.com/python-
poetry/poetry/issues/571](https://github.com/python-poetry/poetry/issues/571)

edit: gah, still hitting baffling errors:

    
    
      $ 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.
    

v1.0.0 generally seems to work smoother though

------
acemarke
For whatever reason, I've never understood the point or actual benefit of
virtualenvs.

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:

\- Top-level dependencies defined in an editable metadata file

\- Transitive dependencies with hashes generated based on the calculated
dependency tree

\- All dependencies installed locally to the project, in the equivalent of a
`node_modules` folder

\- All package tarballs / wheels / etc cached locally and committed in an
"offline mirror" folder for easy and consistent installation

\- Attempting to reinstall packages when they already are installed in that
folder should be an almost instantaneous no-op

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]).

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`.

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.

If anyone's got suggestions on better / alternate approaches, I'd be
interested.

[0] [https://github.com/python-
poetry/poetry/issues/872](https://github.com/python-poetry/poetry/issues/872)

[1] [https://github.com/cs01/pythonloc](https://github.com/cs01/pythonloc)

[2] [https://github.com/jazzband/pip-tools](https://github.com/jazzband/pip-
tools)

~~~
dragonsh
Node and npm are no better than JavaScript tools used for dependency
management. I had a project in node 6.0 refuse to work with node 8 and npm
failed to upgrade. No different than python 2.7 to Python 3.

Just browser and JavaScript silence the errors and might result in things
cannot be seen. This is not the case with Python “No errors must pass silently
unless explicitly silenced”.

~~~
uranusjr
Totally agree; node_modules starts to break horribly when you use the wrong
node/npm command to access it. This is unfortunately causing a lot of
misconceptions because people usually judge tools by short-term
experiementations. node_modules works very well in that scenario and gets the
most love--until it doesn’t, you tear hair for those nasty bugs, and sadly
can’t even convince people with your experience (“it works perfectly for me, I
don’t know what you’re talking about.”)

I guess the node_modules approach is fine for Node, since the native binding
story is quite bleak and no very people are deep into it anyway. But for
Python this would be a complete no-go given how pervasive extension modules
are. I don’t know what went through Ian Bicking’s mind when he first designed
virtualenv, but so many aspects of it just reflects that tight cross-language
integration Python is so good at (the bin/include/lib structure,
copying/symlinking binaries into place, setting up env vars to trick foreign
build systems into working, etc.). I wouldn’t want it any other way even if I
could go back in time and involve in its original design. Well, maybe a few
minor improvements, like offer a more beginner-frieldly interface than
activate scripts, or more heavily promote running the binaries directly, but
the design is just… correct.

------
SaberTail
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.

~~~
beisner
I use this workflow with poetry 1.0.0 just fine

------
yegle
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?

~~~
yegle
This is actually pretty straightforward:

    
    
      pip wheel -w ./wheelhouse -r requirements.txt
    

Then you can modify your script to insert every whl in sys.path. Add
wheelhouse directory to version control and you get a repo that can easily
reproduce anywhere that manylinux is supported.

------
EsssM7QVMehFPAs
Why would I use this instead of Anaconda?

~~~
dguaraglia
They are pretty different tools. Poetry is a dependency manager and packaging
tool, Anaconda is a pre-configured environment for scientific Python.

~~~
aprdm
I guess the comparison would be to Conda which also allows for declaring
dependencies and building environments.

------
starpilot
Is there a good way to build a portable package containing dependencies for
installing on an airgapped system?

~~~
ctrlc-root
Take a look at Twitter PEX. I gave a short talk on it earlier this year
([https://www.youtube.com/watch?v=abnwINA50DE](https://www.youtube.com/watch?v=abnwINA50DE)).

~~~
j88439h84
Pex doesn't support pep 517 but shiv does.

------
MegaLeon
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 -
[https://gist.github.com/leoncvlt/10e67d9415e61eff0f5010ef6fe...](https://gist.github.com/leoncvlt/10e67d9415e61eff0f5010ef6fec51d8#file-
evenvo-bat-L33) \- but interested in giving this a spin!

------
merricksb
Big discussion about project 4 months ago:

[https://news.ycombinator.com/item?id=20672436](https://news.ycombinator.com/item?id=20672436)

------
himynameisdom
Since pipenv is pretty much dormant, this seems to be a nice alternative.
Thanks for sharing!

------
sansnomme
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.

~~~
j88439h84
Nowadays its just --allow-prerelease

~~~
hobofan
If I read the 1.0 changelog correctly, I think you don't need that flag
anymore

------
calibas
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!

------
lkjaero
This looks pretty nice! Definitely reminds me of the node ecosystem.

------
RocketSyntax
it has a nice comparison to pipenv

~~~
dec0dedab0de
I don't think that was a nice comparison.

It just says that he doesn't like the pipenv cli, and some decisions made, but
doesn't say why or how poetry is different.

The only thing it goes into detail with is a bug in pipenvs dependency
resolution, and how their resolver avoids that bug.

------
skept
It's not clear from the current title but Poetry v1.0.0 was just released:
[https://github.com/python-
poetry/poetry/releases/tag/1.0.0](https://github.com/python-
poetry/poetry/releases/tag/1.0.0)

------
juanuys
Looks like Randall's comic needs an update!

[https://github.com/dephell/dephell](https://github.com/dephell/dephell)

[https://xkcd.com/1987/](https://xkcd.com/1987/)

~~~
fermigier
Big up to dephell
([https://github.com/dephell/dephell](https://github.com/dephell/dephell))
which makes it pretty straightforward to convert from one dependency
management system to another, while the dust settles.

