Package using poetry for a better life

[aahnik]

setup.py is a old method. pyproject.toml is modern, and poetry is very convenient.

Should I open a pr ?

[ramnes]

Hey @aahnik, thanks for the issue and offer!

Poetry is indeed a much better tool but as good and widely used as it is, it's not what I would call standard, yet. For example, the thing that's holding me back the most is the lack of support for editable installs. While they don't make sense in the Poetry world, not everyone uses Poetry.

From my experience, a setup.py file is still the most portable way for libraries, i.e. it doesn't get in the path of anyone, whatever tool they're using for their application development. I feel that Poetry and others bring a lot of value for a project developer, but not really for libraries end users. I'm still open to discussion though!

[aahnik]

For example, the thing that's holding me back the most is the lack of support for editable installs.

I cannot understand what you are trying to do. When you are in the poetry shell, any changes made to the package immediately reflect. I think that means it is an editable install.

---

End users can still install via pip when published to PyPI. So what's the problem ?

---

People who will contribute to this project can easily learn poetry, as it's very simple. Poetry also has brilliant docs. Initially, I also had some hesitancy about poetry. But once I started using it, there is no looking back.

And the poetry publish command is so convenient for publishing to PyPI.

Poetry also supports dev dependencies. In the next version, they will be supporting a custom grouping of dependencies. Poetry works smoothly with pytest, if you are planning to test.

Initially, I was confused about the different tools that big projects use. Like pylint, pre-commit , black, isort, mkdocs, etc. But these are extremely helpful for large projects.

After learning about them, I created a template for starting python projects, with everything configured to sane defaults. You may checkout aahnik/pyproject

[ramnes]

People who will contribute to this project can easily learn poetry, as it's very simple.

I do agree it's simple but still, it's yet another tool that doesn't bring much value for someone that would want to just change a few lines on the project, and I don't want to add a mental barrier for potential contributors. I love using Poetry or other similar dependency managers for my personal projects, but it's simply not necessary here and I think it would just add noise. Unless there is some value for new contributors that I don't see?

[ramnes]

Initially, I was confused about the different tools that big projects use. Like pylint, pre-commit , black, isort, mkdocs, etc. But these are extremely helpful for large projects.

Yeah, I'm more interested in these kind of tools for this library. Black is already in use, but pre-commit and isort would be great additions if you want to add these. :)

[aahnik]

I was ignorant of the concept of editable install. After you explanation,

If you're using something else and want to hack on notion-sdk-py while working on your project, pip install -e is the most convenient way,

and this stack overflow answer,

my understanding is that.

suppose I install package X in editable mode. I am working on package Y, which uses package X. If I make changes to package X, in the system, then, changes will be immediately reflected for Y.

Am I right ?

[aahnik]

the link you gave was really helpfull. Thanks. I learned a new thing today.

[ramnes]

suppose I install package X in editable mode. I am working on package Y, which uses package X. If I make changes to package X, in the system, then, changes will be immediately reflected for Y.

Am I right ?

Yes, perfectly right. :)

the link you gave was really helpfull. Thanks. I learned a new thing today.

Awesome!

[bergercookie]

Yeah, editable installs is one of the still remaining pain points of poetry (for non-poetry users, that is)
However, this feature seems to be merged to master lately so I expect it to be solved in the next release 🤞🏾

python-poetry/poetry#34

[CyberTailor]

I suggest to stick with setuptools as it's the de-facto standard build system that can be also used with pyproject.toml.

Using setup.py directly is deprecated and discouraged.

Linux distros switch to PEP 517 build backends for packaging too as they can't rely on setup.py install anymore.

[ramnes]

That blog post says:

This does not mean that setuptools itself is deprecated, or that using setup.py to configure your package builds is going to be removed. The only thing you must stop doing is directly executing the setup.py file — instead delegate that to purpose-built or standards-based tools, preferably those that work with any build backend.

AFAIK pip is one of those tools that work with any build backend, so what's your point?

[CyberTailor]

setup.py can be left but it will contain just these two lines:

from setuptools import setup
setup()

As everything will be configured declarative-style (preferred for PEP 517 builds).

[ramnes]

But what's the benefits of a "PEP 517 build" for the library users and myself as a maintainer, apart that it's the shiny new thing? I'm happy to do the switch if the benefits overweight the cost of changing my habits.

[CyberTailor]

Linux distributions would be more happy to adopt this package, and it wouldn't use legacy build backends. Also devtools configuration and build system stuff are in different places. TOML (will be included in Python 3.11 standard library) is more flexible than INI.

[CyberTailor]

changing my habits

I don't suggest switching to poetry -- all tools and workflows will stay the same.