The changelog for 0.11.0 is lacking

[ddevault]

Doesn't mention the breaking change to the packaging approach (setuptools => poetry), at least.

[ddevault]

After further research, I would strongly advise against switching to Poetry, as it is unsuited for distribution packaging. The change has introduced major regressions.

[liZe]

Hello!

The changelog says that packaging has been updated.

We actually don’t use poetry to package Pyphen, but flit (see the first lines of the pyproject.toml file). What are the major regressions you met?

[ddevault]

Well, it says "updates packaging", but leaves it to the reader to go find out what actually changed, and how their environment needs to be updated accordingly.

The absence of setup.py broke my build. I looked up pyproject.toml and found poetry, which I assumed was the new packaging system. Any guidance at all from the changelog would have been helpful in avoiding this mistake.

In general though I would strongly advise against changing things like packaging systems without a very strong reason to. Why break what isn't broken?

[liZe]

The absence of setup.py broke my build. I looked up pyproject.toml and found poetry, which I assumed was the new packaging system. Any guidance at all from the changelog would have been helpful in avoiding this mistake.

We’re sorry to see that your build was broken by this change. We didn’t know that some users also build packages from the git repository, we assumed that they used the package we provide on PyPI.

If you want a setup.py file, it’s included in the source package on PyPI. It’s probably better to rely on this source package than the git repository if you want to build the package yourself, because these source packages are somehow normalized and don’t change much when the packaging system changes.

If you really want to build the package from the git repository for some reason, you can use flit: pip install flit, flit build.

In general though I would strongly advise against changing things like packaging systems without a very strong reason to. Why break what isn't broken?

We didn’t change the packaging system only to break your builds :wink:.

The Flit documentation includes a page explaining why using Flit is useful. Maintaining packages using setuptools has caused us may problems in the past, and using Flit really helped us. Moreover, all the packaging information is now in one file (pyproject.toml), that’s cleaner. And calling flit build and flit publish is a real pleasure, compared to what we used to do :smile:.

[ddevault]

I've published Python packages, too, I'm not unfamiliar of the process or its limitations. But flit is one of 20 attempts to "fix" this, and none of them does everything setuptools can. setuptools has the enormous advantage of being standardized, which means that for each one of the hundreds of Python packages I interact with, I can use the same process and expect the same features. Any fix or improvement which addresses an edge case was already done for setuptools 10 years ago, and every niche package manager will have to re-invent every single wheel, slowly and painfully, over the course of several years, causing problems for users, programmers, and packagers the whole while.

The math does not work out. Just use setuptools. It's what a responsible engineer would do.

[liZe]

The math does not work out. Just use setuptools. It's what a responsible engineer would do.

Saying that I’m irresponsible is not the best way to make your point and to convince me :smile:.

Flit is just a tool to create packages. These packages are compatible with setuptools, with pip, with the Python packages ecosystem. It’s not an attempt to "fix" setuptools, it’s a tool that creates packages compatible with setuptools.

We’ve been using Flit for quite a long time now, for many packages, and nobody actually complained. It saved us a lot of time and fixed many issues. For our users, usually, it doesn’t change anything: packagers use the source package (that use the same format as usual), end-users use pip and install the wheel, and everybody is happy.

So I’m really sorry to see that we broke your workflow, and we’ll be happy to help you find a solution that pleases you, and that pleases us too.

You say that setuptools is standardized, but I actually disagree on this point. I think that this rationale is a good explanation, As you probably know, setuptools was built outside of the Python standard library, and has been used by everybody without being actually standardized. That’s a reason why PEP-518 has been written: Python needed a standard way to build packages, without depending on third-party tools like setuptools.

Defining pyproject.toml in various PEPs was (in my opinion, and also in the opinion of those who accepted these PEPs) a great solution to:

• keep the compatibility with packages available on PyPI,
• keep the compatibility with setuptools/pip that are used to install packages,
• have a real standard way to store the package metadata,
• allow third-party tools to build compatible packages.

Having pyproject.toml standardized actually means that we don’t have to rely on a tool. We can rely on a standard format that tools follow.

[liZe]

I have updated the changelog :smile:.

[ddevault]

Thank you.