Could the tool.poetry settings be made optional?

[nottrobin]

Poetry's pyproject.toml, as I understand it, is intended to be a potential replacement for both Python packages (setup.py) and projects (requirements.txt). Much like package.json which it appears to be kind of modelled on.

pyproject.toml seems to require the same settings as setup.py:

The Poetry configuration is invalid:
  - 'name' is a required property
  - 'version' is a required property
  - 'description' is a required property
  - 'authors' is a required property

But I want to use Poetry within projects that are not packages, where it is replacing requirements.txt, not setup.py. These projects are not versioned. They are websites where the main branch is continuously deployed to production, and versioning is unnecessary. Similarly, there's no particular value to maintaining a canonical list of authors.

package.json does not require you to define version or name to use it for simply npm installing dependencies, and so we often don't set them in our projects.

Might it not make sense for Poetry to follow this same model, and only require the existence of name, version etc. at the point that you ask it to publish the package, rather than as a core requirement?

[neersighted]

It's a little more complicated than that -- Python packages are typically meant to be installed. We would have to require the metadata during poetry install without --no-root for instance, which is more surprising to the user and harder to maintain in code.

It's also possible that we could generate filler metadata in that case, but that strikes me as quite surprising, and it being better to make the user explicitly specify what metadata they want, since it's hardly burdensome -- an example of this is in our own website: https://github.com/python-poetry/website/blob/main/pyproject.toml

Granted, for many packages (say, Django, or likely what you are doing), they may never install the 'root package' and only use Poetry to create a virtual environment with locked package versions. However, as Poetry is a general packaging tool for the Python ecosystem (and tries to be similar to other tools/encourage best practices in the ecosystem), I'm don't think this is too surprising either.

I think this might make the most sense in a world where we support a library, application, and non-package mode that mutates Poetry behavior, as has come up as a suggestion multiple times. But I also think that there's a lot of behavior we have to flesh out (plus the PEP 621 transition) before we get to the point where we can reason about definite requirements for a hypothetical multiple-behavior Poetry.

[nottrobin]

Thanks for the thorough reply.

It's a little more complicated than that -- Python packages are typically meant to be installed. We would have to require the metadata during poetry install without --no-root for instance, which is more surprising to the user and harder to maintain in code.

Good point, you're absolutely right that this request is inseparable from the question of whether poetry installs the root package. I can see that these options are required for installing the root package. The installation of the root package is actually another significant unnecessary cost of using Poetry for non-package projects, so it's a good thing the --no-root option exists.

I think this might make the most sense in a world where we support a library, application, and non-package mode that mutates Poetry behavior

Isn't the existence of the poetry install --no-root basically already that mode? Could we therefore make it so that including the --no-root option doesn't require you to define version, authors etc.?

However, as Poetry is a general packaging tool for the Python ecosystem

This is probably the core point. It seems you do basically consider Poetry as a packaging tool rather than a dependency management tool. This is maybe just my misunderstanding. The important question is how true is this - are you really saying that poetry should just be considered as a packaging tool and therefore it's only loosely recommended, or maybe not recommended at all, for non-package projects?

I don't feel this is really true though. I think Poetry is intended to be a packaging tool for all of Python, to generally replace pip. This would again make it similar to package.json. And it seems intuitively clear to me that the number of non-package Python projects out there must exceed the number of actual packages - since after all the point of a package is for it to be used in other projects.

I would suggest that it's quite likely that Poetry is already used in more non-package projects than actual packages. This is not easy to prove conclusively though.

As I see it Poetry can effectively take one of two positions:

• Poetry is a replacement for all of Python and therefore should prioritise a smooth and efficient experience for non-package projects and packages alike. Or:
• Poetry should state clearly that it's not intended for non-package projects and officially recommend another solution (e.g. pip, Pipenv, etc.)

[neersighted]

Isn't the existence of the poetry install --no-root basically already that mode? Could we therefore make it so that including the --no-root option doesn't require you to define version, authors etc.?

I think I already addressed that:

which is more surprising to the user and harder to maintain in code.

---

I don't feel this is really true though. I think Poetry is intended to be a packaging tool for all of Python, to generally replace pip.

Poetry is a replacement for all of Python and therefore should prioritise a smooth and efficient experience for non-package projects and packages alike. Or:

This is the current stance. However, we currently have one set of universal behaviors and defaults for the entire ecosystem. As such it's much more straightforward and unsurprising to cleave to existing standards and conventions than it is to be subtly incompatible.

I do think it is valuable to introduce these behaviors -- but not piecemeal where they may result in bugs with Poetry and surprise users due to documentation and tutorials mismatching. Changing these semantics as part of a holistic approach where the behavior of Poetry itself is requested to change by the user makes more sense, and also makes the matrix of changes easy to opt-in or opt-out of, as well as making the surface area possible to reason about for testing.

Basically what I'm saying is that I see the value in what you've proposed and would like to support it, but not by breaking existing semantics in a way that is backwards incompatible and difficult to reason about in docs (for the end user) and code (for Poetry contributors).

[nottrobin]

Cool. Yes I also don't want to rush a solution. So could we discuss here what the shape of an elegant and obvious solution would be? Or are you saying that discussion is already happening elsewhere?

You mentioned:

I think this might make the most sense in a world where we support a library, application, and non-package mode that mutates Poetry behavior, as has come up as a suggestion multiple times. But I also think that there's a lot of behavior we have to flesh out (plus the PEP 621 transition) before we get to the point where we can reason about definite requirements for a hypothetical multiple-behavior Poetry.

Could I get involved in discussing and fleshing out those modes?

[finswimmer]

There is feature request for the "non-package mode": #1132

Other discussions take part from time to time on discord.