beeware / briefcase

Tools to support converting a Python project into a standalone native application.
https://briefcase.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
2.59k stars 365 forks source link

Make briefcase look for the requirements in the in the [tool.poetry.dependencies] section of the pyproject.toml file by default. #1367

Open amorimds opened 1 year ago

amorimds commented 1 year ago

What is the problem or limitation you are having?

I cannot automatically integrate the poetry requirements ([tool.poetry.dependencies] in pyproject.toml) with the briefcase requirements ([tool.briefcase.app.my-app] in pyproject.toml).

Describe the solution you'd like

Poetry is becoming the standard way to manage dependencies of Python projects, it would be nice to have an integration between briefcase and poetry in this regard. So Briefcase will look at the poetry requirements automatically.

Describe alternatives you've considered

-

Additional context

No response

freakboy3742 commented 1 year ago

I disagree with your assertion that Poetry is the standard way to manage dependencies. It's certainly a way that some people are using to manage dependencies, but it's a long way from being even a defacto standard.

I don't have any fundamental objections to supporting Poetry's conventions for specifying a list of dependencies; the problem with this as a general approach is that tools like poetry aren't (to the best of my knowledge) sufficiently expressive to describe the requirements for a Briefcase app. A briefcase app doesn't have a list of dependencies. It potentially has one per output format.

If this were to be added, it would need to be "opt in" - that is, you'd need to either (a) explicitly declare somehow that you want to use Poetry dependencies, or (b) have poetry dependencies be something that are not required, but will be honoured if present. It definitely wouldn't be accepted as a "default", which suggests an "if you haven't specified your dependencies with Poetry, the config will break" approach.

There's also the interaction with PEP621 metadata to consider. Unlike poetry, PEP621 is a standard, and any implementation would need to consider how the two interact.

This proposal is also related to #476.

ulope commented 5 months ago

As a note, Poetry does support arbitrary dependency groups: https://python-poetry.org/docs/managing-dependencies/

freakboy3742 commented 5 months ago

Thanks - however, to my mind, this isn't really dependency groups; it's an orthogonal grid of concerns. A project can have test dependencies, and it can have macOS/Windows dependencies. There needs to be a way to say "Install this test dependency, but only on macOS"; and I'm not sure I see how you do that with Poetry unless you make a "test-macOS" and "test-windows" dependency group.

There's also the issue of being able to run Poetry so that you can install the dependencies for platform X while running on platform Y.