Support for application-first, library-first, and non-package modes that change Poetry defaults

[thejohnfreeman]

• [x] I have searched the issues of this repo and believe that this is not a duplicate.
• [x] I have searched the documentation and believe that my question is not covered.

I'd like to be able to use Poetry to manage a virtual environment for a project that I never intend to package or publish.

My particular use case is that I want to use Python for testing a project written for another language. I just want to use Python as a cross-platform scripting language that comes with a nice test framework (pytest). I don't want to have to give my project a name or version in pyproject.toml, but Poetry refuses to create a virtual environment or install any dependencies until they are given. Pipenv doesn't have this limitation (because it doesn't try to handle packaging, which would require a name and version), so I'm using it in the meantime. I love Poetry, and I would rather use one tool, so please consider limiting name and version checks to the methods that absolutely need them.

[jacebrowning]

The --no-interaction mode (-n) will infer the name from the directory:

$ cd <my_project>
$ poetry init -n
$ poetry add pytest
$ poetry run pytest

This has worked for all my application projects (e.g. Django) that will never be packaged.

[thejohnfreeman]

Yes, and the version is defaulted. In my use case, this is sitting in a project that has a name and version in another language's ecosystem. Choosing a name is not difficult. There are two good reasons I don't want to have to give a version, though:

• I don't want the "dummy version" in pyproject.toml to confuse newcomers into thinking that there is a Python package cohabiting with the rest of the project. The project has a version that is tracked in another file specific to the other language's ecosystem.
• I don't want me or someone else to accidentally run any commands that might try to package or publish this project to PyPI. I want Poetry to warn that packaging is not possible for this project.

And If I'm not giving a version to Poetry, I might as well not give a name either.

[mwchase]

As a general workaround for the second point, you could add a trove classifier starting with "Private ::", per https://github.com/pypa/warehouse/pull/5440

[shelper]

I also want the option to configure the project that poetry manages as a non-package. not always want to package the project, e.g., could be a ML or DS project

[neersighted]

Renamed to better capture the intent and make this the round-up issue for related duplicates.

[johnthagen]

As prior art to potentially draw inspiration from, see huak, yet another Cargo-inspired Python workflow manager:

• https://github.com/cnpryer/huak/blob/master/docs/user_guide.md#or-initialize-an-existing-project

huak distinguishes between library and application-like projects. Projects default to the library type if a type isn't specified. Specify the type with either the --lib or --app flag.

After testing it, I noted that huak new --app adds an additional src/main.py, and a script in pyproject.toml:

[project.scripts]
test-app = "test_app.main:main"

It's a small start, but I think this is the idea that Poetry could go down to begin treating and thinking about applications (e.g., a FastAPI app) differently from wheel-packaged libraries.

[followben]

I came here via #2458, but as an application developer working with fastapi I was also surprised coming from pip that poetry created a root package by default. --no-root isn't onerous, but would be good to have an application-first switch to use poetry for dependency management only and not for packaging my app.

Given the issue consolidation this something we can expect on the roadmap @neersighted?

[silverwind]

Seconding this request. I think the only change necessary is that the [tool.poetry] section should be made optional, so instead of

[tool.poetry]
name = "foo"
version = "0.0.0"
description = ""
authors = []

[tool.poetry.dependencies]
python = "^3.11"

a minimal pyproject.toml would just be

[tool.poetry.dependencies]
python = "^3.11"

Neither Pipenv nor npm require this useless metadata like poetry currently does.

[con-f-use]

Don't know if exactly related, but there's superficially similar discussion by the PyPA people.

And also my similar (ill-conceived) issue: https://github.com/python-poetry/poetry/issues/8292#issuecomment-1672943259

[johnthagen]

I think the only change necessary is that the [tool.poetry] section should be made optional

This is a good idea. We'd just need to make sure that publish is disabled since one thing that is important in [tool.poetry] even for applications is to prevent accidental publishing of private code:

[tool.poetry]
...
classifiers = [
    "Private :: Do Not Upload",
]

Since we do not yet have:

• 1537

But, given that applications in this configuration couldn't be built as a wheel, I think applications would get "private"-ness as natural consequence of this change?

[radoering]

IMO, it makes sense to introduce an option to allow different modes. I understand the "non-package" mode:

• metadata like name, version and so on should not be required
• --no-root should be the default

But what is/should be the difference between "library" and "application". IIUC, for some users "application" is the same as "non-package", but there are also applications that will be packaged. Thus, is it sufficient to distinguish between "package" and "non-package"?

[scy]

Just to add one more use case here: I'm currently using Poetry simply to define & install dependencies for a MkDocs-based website. There's no Python code inherent to the project, nor does it make sense to publish anything to PyPI.

I guess that's also an instance of "non-package mode".

[radoering]

I drafted a PR to introduce a "non-package" mode: #8650

Documentation is still missing, but the PR description and the pyproject.toml added for testing should be enough to give it a try. Please give feedback if this mode satisfies your use cases.

[codethief]

Adding one more use case that's somewhat similar to @radoering's: We have a monorepo of $NON_PYTHON projects where we use Python scripts for scripting (especially CI jobs, commit hooks etc.) Neither script is a standalone application or a library or anything. Like others have said before, we just use Poetry for dependency management.

On the note of dependency management, the following may or may not also be relevant for the current discussion: I don't understand why Poetry forces me to specify a Python version in tool.poetry.dependencies, given that Poetry doesn't install or manage my Python versions. (I use asfd and a .tool-versions file for that which I now have to keep in sync with pyproject.toml somehow.) Why can't Poetry simply use the Python version I installed it / run it with (depending on virtualenvs.prefer-active-python)? If I remove the Python version from tool.poetry.dependencies I get several errors about how

The current project's supported Python range (>=2.7,<2.8 || >=3.4) is not compatible with some of the required packages Python requirement: […]

Anyway, should I create a separate ticket for this or do people think this ties into the current discussion (and MR)?

[tobiasfeil]

I have a bash alias for poetry install, because it's cumbersome to type the whole shebang every time, so I'll just add the --no-root option to the alias.

[silverwind]

I have a bash alias for poetry install, because it's cumbersome to type the whole shebang every time, so I'll just add the --no-root option to the alias.

Imho, no-root should be made a setting as well in addition to the CLI option, so that it can be set in poetry.toml.

[codethief]

@silverwind …which brings us back to https://github.com/python-poetry/poetry/issues/2458 :)

[nextmat]

https://github.com/python-poetry/poetry/pull/8650 looks like it will address needing to use --no-root, and it is currently scheduled for the 1.8 release (https://github.com/python-poetry/poetry/issues/8770). 🚀

[rnickle]

The addition of:

[tool.poetry]
package-mode = false

In #8650 looks perfect for my use case.

I'm developing an Ansible collection I would like to package with Galaxy, but I prefer to manage dependencies with Poetry.

Thank you very much!

[yrro]

Thanks for implementing this. For those reaching this issue from a search engine, the documentation for enabling non-package-mode can be found here: https://python-poetry.org/docs/basic-usage/#operating-modes

[nextmat]

Thank you again for getting this in! Updated link since the above 404s for me:

https://python-poetry.org/docs/basic-usage#operating-modes

[github-actions[bot]]

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.