Consider using poetry for packaging

[zmievsa]

With poetry, it's slightly easier to start contributing to ideas. It also simplifies publishing, is a bit more readable, and really popular in community right now.

[aroberge]

How does poetry make it easier to contribute? I'm really curious to know!! That's the only reason I would consider to changing.

How, and what would you contribute to ideas if I were to switch to using poetry?

As for your other points:

As a maintainer of many projects, none of which use poetry, I have a set up that works well for me. You mention that it "simplifies publishing"; since I am the one that publish ideas (and my other packages), how would it simplify my current workflow which simply involves executing a single .bat file (on Windows), which I copy from existing project when I start a new one. I don't need to install anything external (like poetry).

Popularity: in 20 years of Python programming, I have seen many "popular" tools come and go. Migrating to using a new tool require a time investment which is often counterproductive. So, being "popular" is not a winning argument for me. However, there might very well be some valid reasons as to why it is popular, which could be worth investing some of my time in learning how to use poetry.

[zmievsa]

I completely agree that popularity is not a valid argument. And neither is the workflow if you already have the one that works.

As a contributor, I feel like running poetry install in the cloned project to set up all dependencies and virtualenv is a lot easier than figuring out each project's way of doing things.

Personally, I love what you've accomplished with this project and I also like to discover weird magics that can be used within python. I am most likely not going to be an active contributor of examples (besides my own projects such as pysh and rupython). However, I am all in to add more features and do some refactoring.

[aroberge]

@Ovsyanka83 I will try to find some time to read up on poetry this week and see if it might work for me.

One thing I do for many of my projects is to set up different virtual environments for different Python versions (sometimes more than one for a given Python version: for example, to test with IPython) and I have simple batch files to switch environment, run tests in one (or all environment), etc. It works well for me, but I do recognize that it is not as simple as doing poetry install.

[zmievsa]

Your workflow sounds really similar to what tox does. There are packages that interface poetry with tox but three more dependencies sounds a little too much of an addition to your workflow :)

[leycec]

True story: I passionately abhor poetry. poetry was the first to market, so it won all the mindshare. But poetry was also nearly impossible to install in a sane standard way for the longest time, because it shipped a non-standard get_poetry.sh Bash script installer internally leveraging curl in unsafe ways to fetch and install itself to the local filesystem. ^{...not kidding} For in(s)ane reasons, poetry also splits itself across multiple subprojects (e.g., poetry-core and so on) – each of which are non-trivial to package and install under system-wide package managers (e.g., Arch pacman, Debian apt, Gentoo emerge). That's why you still can't install poetry as a standard system-wide package under most Linux distributions.

In other words, none of these claims are factually accurate:

With poetry, it's slightly easier to start contributing to ideas. It also simplifies publishing, is a bit more readable...

Instead, everyone who hates setuptools in 2022 might consider either:

• Python Development Master (PDM). Subjectively, this is what I'd go with. PDM is probably the future of Python packaging, because it's the most standards-compliant of the setuptools alternatives.
• Flit. I'm unclear if anyone actually uses flit in the wild, but it's always cited as a valid alternative to poetry – so there you go, I suppose.

PDM Master Race: let's do this. Just kidding! I still use setuptools across all my projects, because it "just works." Ain't nobody got scarce volunteer time to continually wrestle with moving targets that continually pull the rug out from under you.

[zmievsa]

@leycec , let's go through your claims in order.

poetry was the first to market, so it won all the mindshare

both flit and pipenv have been released way earlier than poetry

poetry was also nearly impossible to install in a sane standard way for the longest time, because it shipped a non-standard get_poetry.sh. Bash script installer internally leveraging curl in unsafe ways to fetch and install itself to the local filesystem.

It may have been the case in the past. Now poetry has moved on to get_poetry.py and is moving to install_poetry.py which seek to remediate many issues from get_poetry.sh.
In fact, poetry and pdm installation instructions are nearly identical. PDM was inspired by poetry and a majority of its features and methods are exactly the same as poetry's. But you criticize poetry for its installation while applauding pdm. So what's the difference?

For in(s)ane reasons, poetry also splits itself across multiple subprojects

How is that a problem? It's an incredibly common pattern to split complex applications into multiple simpler applications with dependencies. It does not make them harder to install in any way

each of which are non-trivial to package and install under system-wide package managers

poetry on arch linux and its derivatives is installable using python-poetry package through a single command. Every other distribution has a different default system but on every single one of them install_poetry.py, pip and pipx installations for poetry are available and easily usable. Moreso, there are many examples of python software that is unavailable as a regular system package and is only installable through PyPi -- I do not see any issues with that.

In other words, none of these claims are factually accurate

I do not see how "simplifies publishing", "is a bit more readable", and "is really popular" claims are disproved by any of your points. Even if everything you've said is true, which it isn't, none of my claims are affected. You have not touched its popularity or readability. And your claim about poetry being hard to install does not affect the simplification of publishing packages.

PDM is probably the future of Python packaging, because it's the most standards-compliant of the setuptools alternatives.

How is that the case? Could you provide any proof at all that all other managers are less standards-compliant than pdm? In fact, the only standard PDM supports that Poetry doesn't is PEP 582 which is still a draft. So basically you are recommending to use a tool that is based on a standard that hasn't even been finished yet, i.e. it could change in its entirety and all of the developers using PDM will be affected. How is that a good thing?

I'm unclear if anyone actually uses flit in the wild, but it's always cited as a valid alternative to poetry – so there you go, I suppose.

The author of FastAPI, Sebastian Ramirez, has used flit for both FastAPI and Typer. However, he himself switched to poetry with his SQLModel and has publicly recommended to start new projects using poetry.

[aroberge]

While there might be some advantages in moving to using poetry or some other similar tool, I've decided to close this issue as I'm not ready to invest the time to change my setup. I may try to use it when I start a new project and will use the experience to see if I should use poetry with ideas and various other projects.

Thank you for the original suggestion, which I will keep in mind.

[aroberge]

Reopening as I plan to use this project as a test case for poetry. See also #34