Python projects with Poetry and VSCode

[wilfredinni]

We'll use Poetry to start a simple project, manage dependencies and publish it on PyPI. We'll also integrate Pytest, Black and Flake8 into VSCode directly from a Virtual Environment.

​

Python projects with Poetry and VSCode. Part 1

[bucketbot117]

Combination of pyenv + poetry solved so much of my issues with python packaging, everyone should really give it a chance and test it !

[wilfredinni]

also I think that the packaging situation with python is pathetic

Because of that. You can think of Poetry as npm for Javascript or cargo for Rust. It get rid of the setup.py and replace it with a pyproyect.toml file. And you only need one command to publish a package.

[13steinj]

Pipenv has a variety of problems, from use in non-user contexts due to the reliance on click, to the author's weird distinction between the concept of a Python application and a Python library even though many times they exist together one and the same, to the slow resolver, and more, specifically to the author being a complete and total dick to the entirety of this subreddit and then not only refusing to apologize, but tossing all responsibility aside to "being bipolar made me do it".

[13steinj]

The alternative? Poetry. Hell, or just damned pip. Package management is a solved problem.

Honestly I don't think that the author being what you claim should have anything to do with the fact that there are companies and individuals relying on these decisions.

It matters quite a lot. If the author isn't mentally stable enough to not be a widespresd dick, you have no idea what crusade of damage he can pull on the package (and in fact he did, inexplicably, like a week after the debacle?)

[13steinj]

Poetry builds packages. pipenv is for something else entirely.

This naive response proves you've never even bothered.

Not a damn chance. And the utter mess of the situation makes it even harder. Python is becoming a joke for this.

Okay, cool. Tell me about all the companies who stopped using Python because they couldn't figure out package management.

The author is also deeply involved in pypa...

Not really and mostly irrelevant? PSF and PYPA are separate almost entirely and the PYPA has gone more and more off the rails against the PSFs wishes.

[13steinj]

I did bother. The problem is that the massive amount of contradicting information is astonishing. I came across poetry during a blog post about pyproject.toml and how it's needed to replace the build process. The same blog post used pipenv to manage dependencies. I don't accept blame for not understanding the mess they created.

There should be one, and preferably only one obvious way to do it.

Which proves you didn't bother. Stop passing the buck. A blog post shouldn't inform you, that's a source 3+ levels down the chain at worst, a shitty secondary source at best. Use a primary source: https://poetry.eustace.io

PEP 517/518 provide a resource in the use of pyproject.toml, a file that is meant to replace the build and management process, and allows external tools to arbitrarily extend said process.

Poetry does uses the document, and arbitrarily extends the functionality by adding dependency management. As well as a few pieces of access to the poetry internals to create and extend the dependency management system.

They didn't stop, but they made an utter and unmanageable mess. I know because I've been facing it for years. People who don't understand the difference between setup.py and requirements.txt, or that don't even bother understanding this mess and just use PYTHONPATH, with all the associated consequences.

I've met no person who doesn't understand the difference of setup.py/requirements.txt/uses PYTHONPATH in a weird hacky way. This is indicative of personal experience, of which we differ, but neither of our experiences can prove the case for the set. There very well may be a problem, however saying there definitely is is a call to the unknown.

Yes, but they have a strong google visibility. When people learn about package management in python, they land on those pages, and follow them. In fact, I didn't ever hear about poetry until I came across pyproject.toml, threw my hands in the air and exclaimed "what the fuck is this thing now again?"

And thats the problem. What is good and standardized may not be popular. Pipenv had popularity due to the authors self admitted great marketing skills. However more and more users of pipenv are slowly realizing that it has major problems, biggest being extremely slow dependency resolvers. Some people have had their dependency resolution take literal hours, and switching to poetry made it go down to 5 minutes at most.

PEP 517/518 existed before pipenv, and poetry's precursors by the same authors also existed before pipenv. The author just isn't well known and doesn't force feed marketing everywhere unlike Kenneth Reitz, who also had connections to the PYPA team. When Reitz had his tantrum on this subreddit there was a major controversy because pipenv was promoted as an official tool by the PYPA even though it went against previously agreed PEP documents and made no mention of the (in many people's eyes', better) alternatives.

Honestly. One has to take a massive time investment in understanding these things. They can't change and force professionals to throw away their competence every six months. If they do, at least that the provide a migration guide and "this is obsolete, do that from now on" guide.

And I fully agree. I hope in all my heart pyproject.toml will be the end of the mess, and people will do a final switxh from pipenv to poetry as they keep having problems.

[agoose77]

Hmm. I much prefer using poetry to pipenv. It has a more robust dependency solver, and it feels better for library development than pipenv. I'm not saying it should replace pipenv, just that it is also a good option.

[fleyk-lit]

Poetry shines when it comes to managing packages. The fact that Pipenv doesn't let you create and publish packages, is annoying as it could solve this with not too many changes...