Parse settings from pyproject.toml

[miigotu]

This project is the last of my dependencies that can only read from setup.cfg. the domains that I think should be used are something like:

pyproject.toml:

[ tool.babel.extract_messages ]
message_extractors="""{
 'gui': [
 ('**/js/*.min.js', 'ignore', None),
 ('**/js/*.js', 'javascript', {'input_encoding': 'utf-8'})
 ]}"""
#options
[ tool.babel.compile_catalog ]
#options
[ tool.babel.init_catalog ]
#options
[ tool.babel.update_catalog ]
#options

[miigotu]

@akx @benselme @blagasz @kvesteri @mitsuhiko @sils
Sorry for the ping but I'd really like to see this, and I'm willing to add a PR to make this happen. Before I waste my time, is there a policy or stopper against accepting a change pr that accomplishes this? I just don'y want to waste my time if so.

[miigotu]

I'd also like to submit a patch for the f-string problem. There is not a nice way to do it, but I think we could add a hack for it (which includes a small speed expense) that depends on a config/pyproject setting or environment variable or something to enable. Possibly with a new/different import when you gettext_install. That way it would not be a breaking change, and would avoid slowing down every implementation unless they enabled the feature.

[akx]

@miigotu There's no policy or stopper preventing a PR for pyproject.toml.

However:

• care should be taken to keep Babel working even when no TOML capabilities are present,
• the format of the TOML configuration should be well-thought-out in advance. The draft in the original message here seems a bit icky with a Python literal being embedded in the TOML.

As for "the f-string problem"... I think that's quite unrelated here?

[miigotu]

Yeah I messed with the spec for it a bit last night, and pulled a global options out. Toml allows multiple definitions of the same key, so

[tool.babel.config.extractors]
type = "python" 
options =
paths =
match = "**/source/*.py"

[tool.babel.config.extractors]
type = "js"
match = "**/js/*.js

Works, but I need to think about it more.

[AbdealiLoKo]

Is my understanding right that if I am not using setuptools I cannot use any config file (even setup.cfg) ?
i.e. the pybabel CLI command does not read from any config file ? the only way to give it inputs is the command line arguments ?

I don't mind not using pyproject.toml - but if pybabel could read from a .babel or .babelrc or even just take configs from setup.cfg ... that would be fine

[miigotu]

Ideally nobody should have to add a secondary config file to their project when pyproject.toml is the preferred and python team recommended method for new projects, and handles all possible use cases in the spec for any tools that is willing to implement their config from it. It was sort of the purpose of the pep, to make it so we didn't need 10 different files for configuration cluttering up our source code, and searching all over the place for where settings came from in larger projects. Setuptools is being phased out in most projects. I understand keeping backwards compatibility, but forwards compatibility keeps tools relevant for people who are perfectionists and prefer some level of interoperability and conformity to standards.

[jpmckinney]

Setuptools is being phased out in most projects

? What are people using to build packages if not setuptools? (enscons?)

[AbdealiLoKo]

I am moving a package to use poetry - I pinged about the config file because of this

I also use basic build in some projects

[miigotu]

Setuptools is being phased out in most projects

? What are people using to build packages if not setuptools? (enscons?)

Poetry or flit are the leading tools to package new projects.

Peps 517, 518, 621, 631, 633, 660 (and more) provide for pyproject.toml to include project metadata, build system information, dependencies (including extras and optional named groups), configuration for third party tools and requirements in the expanded toml, elimination for the need of requirements.txt, requirements-dev.txt, requirements-win.txt, setup.py, setup.cfg, and numerous other files in a project. Ideally, a project should only need a readme, pyproject.toml, code, and possibly contributing.md and a LICENSE file. Everything else can be handled in the pyproject.toml provided the tools you use read configuration from it.

I use about a dozen tools in my project, python-babel is the only one that does not check the pyproject except for .editorconfig.

https://github.com/python-poetry/poetry
https://flit.pypa.io/en/stable/

These eliminate the need for multiple tools to build, package, and publish separately. Adding/removing depends, installing (editable or not), multiple virtualenv functionality for testing or building, building/packaging, and pushing to pypi are all handled with one tool.

Particularly with poetry, you dont need to use virtualenv, pipenv, tox, twine, pip, setuptools, pyenv, or anything. You can even define custom commands to run, inside the pyproject, using poethepoet. It's a complete tool, that is extensible with plugins.

Setuptools itself even works and reads config from pyproject.toml https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

[jpmckinney]

FWIW flake8 also doesn't support pyproject.toml PyCQA/flake8#234

Anyway, this project is open to a PR so why not just contribute one? #777 (comment)

Edit: Off-topic, but I use the pyenv-virtualenv Homebrew package, which automatically installs pip and setuptools, and pip-tools for my applications (not my packages). Then I use the https://github.com/pypa/gh-action-pypi-publish GitHub Action, which uses twine to publish the package. Don't need pipenv (alternative to pip-tools) or tox (just create a matrix in GitHub Actions). I guess one CLI with many packages as plugins might be preferred to multiple CLIs from many packages... Anyway, +1 to pyproject.toml support – I prefer to have fewer config files, too.

[akx]

Poetry or flit are the leading tools to package new projects.

I disagree - I've been starting to use PyPA's own hatch for my libraries as that's what the official tutorial primarily suggests, and build to do the building.

[miigotu]

FWIW flake8 also doesn't support pyproject.toml PyCQA/flake8#234

Anyway, this project is open to a PR so why not just contribute one? #777 (comment)

Edit: Off-topic, but I use the pyenv-virtualenv Homebrew package, which automatically installs pip and setuptools, and pip-tools for my applications (not my packages). Then I use the https://github.com/pypa/gh-action-pypi-publish GitHub Action, which uses twine to publish the package. Don't need pipenv (alternative to pip-tools) or tox (just create a matrix in GitHub Actions). I guess one CLI with many packages as plugins might be preferred to multiple CLIs from many packages... Anyway, +1 to pyproject.toml support – I prefer to have fewer config files, too.

Even though most projects are using something like black/blackd instead of flake8, flake8 does in fact support pyproject.toml
https://github.com/SickChill/sickchill/blob/master/pyproject.toml#L125

[miigotu]

Poetry or flit are the leading tools to package new projects.

I disagree - I've been starting to use PyPA's own hatch for my libraries as that's what the official tutorial primarily suggests, and build to do the building.

What are you disagreeing with? Flit and poetry are the two leading projects for pyproject based projects. I never said they are the ONLY options. Even hatch uses pyproject only.