Please add to the docs the reasons why this tool exists (on a separate page)

[KOLANICH]

• I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Hello. I don't understand the idea behind this tool.

There exists setuptools dealing with building packages. It has been allowing to declare the stuff in setup.cfg for quite a long time. Though it is not pyproject.toml, I guess it can be moved there with time pypa/setuptools#1160 . So I don't understand why to create a yet another package manager and build system (in the best case it would be ignored by people and your effort would be just wasted, in the worst one we'll get a fragmented ecosystem where a user would have to install and support in own packages a serpentarium of different package managers and their dependencies and take care on what package manager to use), not to improve the existing packages.

Could you clarify this in the docs and README.md?

[jhrmnn]

[I'm not an author of Poetry, just a happy user.] Please, make yourself first familiar with the ideas in PEPs 517 and 518 before making comments such as this one. setup.cfg is specific to Setuptools, which is one possible way how to build Python packages, but there is no reason to think it's the only or the best one. Python now officially supports (via the PEPs above) the concept of having multiple build systems for packages. You can think of it as free market, where the best build tool wins. Poetry is one of such build tools.

[KOLANICH]

Python now officially supports (via the PEPs above) the concept of having multiple build systems for packages.

And this IMHO was a big mistake: fragmentation is not a good thing, the main benefit of python ecosystem is its uniformity: when one needs calculations, he uses numpy, when he needs math, he uses scipy, when he needs <something>, he uses <some package everyone else uses when he needs that>. This is beneficial:

1. all the features are in the same package, no situation when a dev needs 2 features when one feature is in one package and another one is in another package
2. no need to develop the same features for many packages.
3. usage of that package is expected, a dev of some auxilary library doesn't have to implement support for multiple packages in it.
4. less redundancy and better security - less de0endencies to be installed.

And when one needs packaging, he uses pip and setuptools. And when one needs to write an addon adding a custom packaging stage, he writes an addon supporting only setuptools, not the serpentarium of differrent packages.

You can think of it as free market, where the best build tool wins. Poetry is one of such build tools.

Free market is definitely a good thing, but here we are not selling products, but working to achive the common goal of having a good packaging system, so competition here is bad thing and cooperation is the good one. One good package manager is better than 100 not so good ones. So one should really have good reasons to start reimplementing something already implemented rather than improving it.

So I consider having a bunch packages for the same thing as bad and harmful. What python ecosystem really needed is the declarative sdist manifest requiring no code execution to build a wheel, so the tooling (like https://libraries.io.io, GitHub, GitLab, safety, etc) can assume that, and this format is the setup.cfg supported by setuptools. If one is not satisfied with pip and setuptools, IMHO he should improve them, not to start own replacements.

[rooterkyberian]

Currently we already have a comparison of poetry vs pipenv. The same maybe done for poetry vs bare setup.cfg (or setuptools as a whole). If you think that is needed its best to create a PR for it.
To get you started I would suggest reading through https://www.python.org/dev/peps/pep-0518/ and pipenv and poetry discussion. pipenv has less functional overlap with setup.cfg, so it maybe easier to see looking at it alone features that poetry offers over setuptools alone (such as dependency locking, single configuration file, virtualenv management, and some basic project bootstraping). Then there are things that differ between pipenv and poetry, and those among other is that poetry tries to free you from setup.cfg and setup.py - you can read some of recent discussion about it here: #488.

The fragmentation/free market discussion is a somewhat idealistic side topic, which I'm unsure should be entertained here, but I hope you do realize that python packaging system has gone a long way since Python emergence and it wasn't a linear development. I see your point about wasted effort, but then again, just talking about things doesn't change much and it is much easier to prove worth of your ideas by giving them a chance to prove themselves - that is implementing them, and hoping world will be better for it. If it doesn't pan out, welp, at least you tried.

[orlnub123]

I'd heavily recommend reading https://snarky.ca/clarifying-pep-518/, it's a great resource on the topic.

@KOLANICH I don't fully understand the implementation and how all the pieces come together but I don't think your analogy on uniformity is correct. Choosing to import and use numpy is an option, you aren't forced to use it instead of a less popular package, or even your own. This is unlike the earlier situation, where you have to use setuptools/distutils if you want to support pip, which every other developer uses.

One thing that I don't like currently and something that contradicts the above is that you're forced to use Poetry in order to install a Poetry-dependent package from source. Thankfully that won't last long as PEP 517 support is getting added to pip.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.