Allow valid version specifier when specifying Black version in pyproject.toml
#4406
Labels
T: enhancement
New feature or request
pyproject.toml
#4406
Is your feature request related to a problem? Please describe.
This could be a user error, and if so, please let me know how to achieve the desired result :)
The documentation states that if we use
version
in the GitHub (GH) action workflow, valid version specifier per Python packaging standards can be used. This means we can do:However, if we have a
pyproject.toml
file for other configurations in addition to version and wish GH action to use the same configuration for checks, we have to usetool.black.required-version
field because as I discovered through trial and error,version
in GH version workflow anduse_pyproject
are mutually exclusive.And when I tried to do
required-version: >=24.3
inpyproject.toml
, I encountered the following issue on GH actions:The use-case here is that I would like to have a way to define a more relaxed version requirement for black in
pyproject.toml
, so we can have the same functionality and options as theversion
option in the GH actions workflow.Describe the solution you'd like
Allow valid version specifier when specifying Black version in
pyproject.toml
, so the syntax will be equivalent to theversion
in GH actions workflow.I will admit that I have not looked into the codebase to determine how difficult the enhancement is. If this suggestion is accepted I would be happy to look into it.
Describe alternatives you've considered
We resolved the issue by downgrading the required version in
pyproject.toml
to 23.4.0 for now.Additional context
How we discovered this was that the readme for the
black
repo states that the latest is 24.4.2. We set up our GH actions workflow to use 24.4.2 but only recently discovered that the release version of the VS code black formatted extension still uses 23.4.0.This causes issues locally as the stated required version in
pyproject.toml
file is not the same as the VS code extension.The pre-release version, as of July 19th, 2024, uses 24.4.2.
I understand that as the new release comes out, this should not be an issue as the extension will support slightly older versions. However, this feels like a bit of inconsistency and would be very nice to have equivalent notations between the 2 fields.
The text was updated successfully, but these errors were encountered: