Black: Non-prerelease black release

[lig]

It looks like Black is stable enough at the moment to release it as stable to PyPI. There are plenty of tools and integrations already which rely on black package and the fact that it is still in prerelease state sometime causes inconveniences, i.e. using it with pipenv forces allow_prereleases flag to be set to true.

[ambv]

This will happen soon, you're right. We'll be releasing one last (planned) beta, and then an RC of a stable release.

[gforcada]

@ambv not to be pushy/disrespectful, but is that soon, actually soon? :sweat_smile:

[ambv]

Right. Surely before Christmas, likely not in November though.

[Aareon]

Looking forward to this as pipenv screams if you try to install without the --pre flag

[massenz]

It would really be nice, as I currently have to do this in pipenv (I don't want by mistake to allow other "pre-release" packages):

black = "==18.9b0"

and it's not really a great practice (as it also prevents me from automatically getting the latest and greatest).

Thanks for creating Black, though - super-awesome!

[Aareon]

I agree. Being able to streamline Black with other development tools is a huge plus. Black is currently a MUST in all of my projects.

[lig]

@ambv Merry Christmas!:)

[dimaqq]

Please? 🙏

[dyve]

See also
https://github.com/alanhamlett/pip-update-requirements/issues/23#issuecomment-456661501

This means we cannot update black in requirements.txt with pur.

A non-beta version would be much appreciated.

[Utsav2]

Black at HEAD has a fix for issue 282, and we can't beta test it at Dropbox until there's a release with that issue fixed. Please consider creating a new release soon.

[Peque]

@ambv Friendly ping. :innocent:

[fernandezpablo85]

@ambv friendlier ping

[max-wittig]

@ambv even friendlier ping :P

[hugovk]

Give the last beta a serious spin for the remainder of March! I'll tag the first stable release in early April.

https://twitter.com/llanga/status/1106247630370283523

[dimaqq]

Cheers @hugovk , it does feel like formatting got pretty stable in black:
2 lines changed in 100KLOC codebase with the latest release :)

[tribals]

Any changes on this?

[zsol]

I hear @ambv loves making stable releases in April, so I have high hopes ;)

[ambv]

FYI, we are sprinting on Black at PyCon now with the target stable release at some point right after.

[max-wittig]

What's the status here? It's annoying to use/install a pre-release package :disappointed:

[Imaclean74]

Still pending ? is there anything blocking the release creation ? or its a matter of someone's time to actually do the work ?

[dvf]

It’s time 🙏

[fernandezpablo85]

@ambv ?

[astrojuanlu]

[ambv]

Hey everyone, I'm sorry this was slipping so long. Long story short:

• I had to move Black under the psf/ org and this had priority, you can't have a stable release and then change everybody's links next week;
• marking the release as stable is a Big Deal to us because it's when we promise not to fiddle with the style anymore, there's a few last things we need to merge or decide on;
• this project is barely 18 months old, please be a bit patient, it's an unpaid labor of love for the maintainers.

[lig]

@ambv I would argue that stable means no style changes in the future though. I'd like to see some sort of style change policy in terms of something like semver. It is obvious, in my opinion, that there always could arise an issue with some formatting. And in case no style change ever after the stable release I would vote for the stable release never appear at all.

[mrocklin]

FWIW as a user I would prefer a release before things are fully stable. Honestly, black is far more stable than most of the software that I use (pandas, scikit-learn, tornado, ...).

I'm also totally fine if you want to fiddle with style in the future. I would actually prefer that black maintainers not promise to never fiddle with style. I'm confident that you all will learn things in the future that you'll want to apply, and I'd prefer that you have some freedom to make those changes.

In general I think that it's perfectly acceptable to release software before it is fully stable. The world runs on and benefits from imperfect software. Obviously y'all should do whatever you think is best, but I think that there is a lot of good that black can do today in its current form.

[rpdelaney]

@mrocklin is right. "We moved to psf" and "we aren't getting paid" are excellent reasons to delay a stable release. But I think "we need to settle some style issues permanently first" isn't as compelling.

A commitment to _never_ making style changes again is likely to lead you to situations where you have to either compromise, or leave in sub-optimal behavior in corner cases that haven't been considered yet.

I'm using black with a pre-commit hook and installing it as a dev dependency via pipenv. That means I can pin the black version to the project if I want to prevent future style changes mucking up the git blame and whatnot. So style changes are not a threat to me.

But it is a threat, however small, that installing black with pipenv is a bit annoying since it requires the use of the --pre switch. As long as there is no stable release, any black version I pin to the project will require me to document the use of the --pre switch for other developers now and forever.

Besides, "we won't make style changes" is a policy decision, not a technical limitation, meaning it could always be reversed (and so anyone who really truly cares about this will have to pin the version somehow anyway).

Stable release please. 🙏

[thomasf]

Why does a stable release matter to you if it in fact does not have a stable output?

I don't see a reason to have black installed in pipenv, maybe I am missing something but I have one black installed for all my python project and it works perfectly even if it's not installed in pipenvs virtualenv. Also, I don't think that being compatible with pipenv (which has heaps of issues on it's own) is maybe a good reason to decide how this project should plan releases.

I fully support the pre-release until formatting is decided MO and preferably moving to semantic versioning so that 1.x never will break formatting or usage.

[Kilo59]

I'm using black with a pre-commit hook and installing it as a dev dependency via pipenv. That means I can pin the black version to the project if I want to prevent future style changes mucking up the git blame and whatnot. So style changes are not a threat to me.

But it is a threat, however small, that installing black with pipenv is a bit annoying since it requires the use of the --pre switch. As long as there is no stable release, any black version I pin to the project will require me to document the use of the --pre switch for other developers now and forever.

@rpdelaney
If you pin the version you don't need to use the pipenv --pre argument.
Just set it in your Pipfile as black = "==19.3b0"

[max-wittig]

@thomasf it doesn't help that pipenv classifies the whole project as preview, if you're using the --pre argument, so I actually need to maintain a special requirements-black.txt file and install it with pip still.

[rpdelaney]

@max-wittig Based on his comment I assume Thomas will rate that as a strike against pipenv, not black.

[dimaqq]

I feel that this thread touches on a related issue — the release cadence could be better.
About 50 PRs were merged since last release.
I think I'll start ti pin black to a commit hash rather than release soon!

Wrt. having or not having a stable release, there are two ways to look at it:

• ideology "what is stable?", and
• usability issue "silly, but users come first"

[dvf]

It seems like we're dealing with two kinds of versions here: one is the actual version of Black (the code itself), the other is the rules of how Black formats code. I think it would make sense to separate these.

I'd love to hear your thoughts @ambv

[paugier]

We also would need a stable (actually not beta) release of Black.

Black is used in Transonic, a new "meta" Python compiler for scientific/numerical codes. In Transonic, we produce Python code from AST analyses and Black is used to have nice and readable codes for the users/developers (and also to avoid useless compilations after style changes). Small style changes between Black versions are really not an issue for us.

I don't personnaly use Pipenv, but some projects using Transonic use Pipenv in their CI. If we add Black as a strong dependency for Transonic (as we should do), all projects using Transonic become incompatible with tox-pipenv.

I don't think it would make sense to pin the Black version for Transonic (which would lead to other problems).

I understand that you care about the stability of Black's results, but (i) semver would be fine to express that and (ii) the idea of two version codes (one for Black's code and one for Black's result) seems good.

[rpdelaney]

I don't think it would make sense to pin the Black version for Transonic (which would lead to other problems).

I agree -- that's evident from your relaxed approach toward style changes within black. A project that has decided to take a more conservative approach still has this problem, though.

the idea of two version codes (one for Black's code and one for Black's result) seems good.

This is an interesting idea but I don't know how a project could pin to an output version, or how conflicts would be resolved when the app version and output version are incompatible, etc etc. As far as I'm aware none of the existing utilities (setuptools, pipenv, poetry etc) would support this.

[paugier]

Dear @thomasf and @carver,

You reacted with thumbs down emoji to my recent message. I guess it means that you think there is a problem with this message. Can you please tell me why?

I'm wondering if it is really a good idea to use this negative emoji for such polite and neutral message... i just express the need of a user.

[thomasf]

No it just means that I don't agree but more importantly your view is already represented further up in the comments so just like this comment which I had preferred not to write it just makes reading the issue more of a chore for anyone new to it or a maintainer. 👎 ( - 1 ) is the most neutral way to just show disagreement by vote without further making the whole comment thread more noisy.

For large projects with many contributions sudden style changes can mean a lot of inconsistencies and special care when merging code if black suddenly start changing how it formats something.

Judging from the other comments in this thread you still have the option to just pin the pre release version to get around that limitation/issue with pipenv if you don't want to wait for a non pre release version which isn't a huge hassle in any way, it even protects your project from sudden style changes.

As an example Django is holding off implementing black into it's workflow until after a non beta release to ensure stable formatting output https://github.com/django/deps/blob/master/accepted/0008-black.rst#timeline

[mar10]

I think (as many others here in the thread) that a real/stable release would make our lives easier.

If we are concerned about finding out later that we need/want changes in the formatting behavior this can be expressed with SemVer. I don't think it's feasible nor necessary to have to different version numbers for the API and the formatting.
Couldn't we simply bump the major version every time when a breaking CLI change is introduced and every time a relevant formatting change is implemented?

I'd call a formatting change relevant if it has the potential to mess up your code 'blame' in a relevant way (which is also a sign that it could make merging difficult).

This would give the maintainers the freedom to change behavior later without being tied to an earlier spec.

And nobody will be surprised by implicitly updating black, but every one could enjoy the new coolness by deliberately incrementing black's requirement.

[paugier]

Judging from the other comments in this thread you still have the option to just pin the pre release version to get around that limitation/issue with pipenv if you don't want to wait for a non pre release version which isn't a huge hassle in any way, it even protects your project from sudden style changes.

It seems that you didn't read the message that you disagreed :slightly_smiling_face:

My project uses black at run time and we don't care at all about "sudden style changes".

Pinning Black version for projects using Black at run time is really not a good idea. if different projects pin different Black versions, they become incompatible just because of Black.

So unfortunately, I don't think there is with only beta releases a way to express the fact that we need Black without potential issues for downstream projects (tox-pipenv broken or potential incompatibility between projects that pin black version).

i don't say that Black maintainers should release a stable version (I don't know). I say that for projects using Black at runtime, no "stable" version is "a huge hassle" and a "stable" version (which could be 0.0.n to clearly show that Black is not "stable") would help a lot.

That said, I really understand that it is not Black's priority to help unimportant users if it is for the good of many other users. But please don't tell me that we are silly to care about a stable version and that it is so easy to deal with this problem (or give me a proper solution). I start to think the proper solution today is just to use another tool than Black. It's just inconvenient, because current versions of Black do very well the job.

[pcraciunoiu]

Been using black for a long time, and I love it.

I'd like to see a non-prerelease as well. I have to use allow_prereleases = true in Pipfile because of this project, and it causes other projects that are more critical to functionality to pull in prereleases as well.

I'm not saying there's no workaround, but if a project has been out for years now... can it have at least one release please?

One workaround is to pin releases for other dependencies. But one point of the lock file with pipenv is to keep updating your dependencies. That would break a lot less frequently for me if this project had a release.

[hnykda]

Hi. Should we give up on black ever have a stable release? It's a great product and I think users can simply manage versions on their own.

[ambv]

https://twitter.com/llanga/status/1187675966694449152

[hnykda]

Thanks for your hard work, black is awesome! It may be a language barrier, but I don't understand the tweet ending:

We will have a stable Black with 19 in the front!

Considering that there has been already about a year since the first "for sure" and then once again after Pycon, I am curious if there is any reason to believe that it's going to be different this time? :grin:

[hugovk]

Black uses calver. It means there will be a stable release in 2019 :)

[max-sixty]

Thanks for the recent release! We had some small breaks over at https://github.com/pydata/xarray/pull/3456 and it made me think of an approach that I've seen work well with other similar projects:

_When introducing breaking changes, deprecate the previous code style with warnings, and only introduce them as errors in a later version_

That way, there's no 'big switch' and CI doesn't break without pinning. Rather, projects can upgrade their syntax whenever works for them. On the downside, running black --check . doesn't 100% mirror whether changes would happen with black ..

Thanks again for the awesome tool!

[ambv]

On the downside, running black --check . doesn't 100% mirror whether changes would happen with black .

I'm sorry, are you sure? --check is doing exactly what the regular run is doing, it's just not writing the file back to disk. Please ensure you don't have any integration magic like using the wrong configuration in the --check run. If you find an example where the behavior is indeed different, it's a rather severe bug so I'd like to know about it.

[max-sixty]

--check is doing exactly what the regular run is doing

Looks like my post wasn't clear! I was listing this as a downside to a proposal, not current behavior.

i.e. if breaking changes were initially deprecated, then black --check . would pass with warnings, but black . would fix code to the new format.

[max-wittig]

Still no stable release with 19 in front as promised here: https://twitter.com/llanga/status/1187675968007278592 :(
Can we have one with 20 in front soon?

What's blocking this? How can the community help?

[revmischa]

By having to enable pre-releases in my Pipfile I've started getting beta versions of libraries and breaking my stuff. Black is the only dependency I have that is a pre-release. Please release a stable version.

[larsrinn]

Huge upvote on this. I don't see a reason for not dropping the b0. We've been using black for 1.5 years on a not so small project and it didn't cause any issues, so it seems like it's pretty stable to me.

Of course there are some changes here and there after version upgrades, but I don't think this is going to go away ever. For exactly this reason, we pin black to a specific version, so we get clean diffs for PRs that upgrade black (and don't change anything else). Maybe this could be the recommended behaviour?

[hnykda]

I am really greateful for all the work devs are putting into this great (opens source!) lib that Python ecosystem is gaining so much from.

But I also have to admit that I am quite disappointed with the communication related to this issue. It has been more than a year since the announcement of the non-prerelease and then several more wrong estimates, without really explaining why or what is happening. I take this quite seriously, as it cascades to suboptimal decision on people who rely on this. E.g. we would have forked black a half year ago already so we wouldn't have to pollute our Pipenv envs with prereleases... It's the second most-commented issue. No offence please, I am just trying to share why it's annoying in the case someone doesn't realize this.

[felix-ht]

Been using black for a long time, and I love it.

I'd like to see a non-prerelease as well. I have to use allow_prereleases = true in Pipfile because of this project, and it causes other projects that are more critical to functionality to pull in prereleases as well.

I'm not saying there's no workaround, but if a project has been out for years now... can it have at least one release please?

One workaround is to pin releases for other dependencies. But one point of the lock file with pipenv is to keep updating your dependencies. That would break a lot less frequently for me if this project had a release.

I just noticed why i was getting beta build for various libs that kept breaking stuff. Turns out someone had added pre_release so black could be installed with pipenv.

The Solution for me is to remove the flag and to pin the black version.

[dev-packages]
black = "==19.10b0"

or

pipenv install --dev black==19.10b0

With this there is no need to set the pre release option in pipfile. I might come back in a year to check if the maintainers managed to stop abusing the pre release flag.

[carver]

For exactly this reason, we pin black to a specific version, so we get clean diffs for PRs that upgrade black (and don't change anything else). Maybe this could be the recommended behaviour?

I disagree. I still think semantic versioning is a worthwhile goal (vs pinning to avoid breaking changes). There are a number of projects that are waiting to use black until it gets locked stable, including some of mine.

Of course, we'd love to have the stable release out as soon as possible, but it's more important to us to have a stable release that's committed to semantic versioning.

[revmischa]

Okay so release 1.0.0 and if you need to make incompatible changes then release 2.0.0?

[revmischa]

Been using black for a long time, and I love it.
I'd like to see a non-prerelease as well. I have to use allow_prereleases = true in Pipfile because of this project, and it causes other projects that are more critical to functionality to pull in prereleases as well.
I'm not saying there's no workaround, but if a project has been out for years now... can it have at least one release please?
One workaround is to pin releases for other dependencies. But one point of the lock file with pipenv is to keep updating your dependencies. That would break a lot less frequently for me if this project had a release.

I just noticed why i was getting beta build for various libs that kept breaking stuff. Turns out someone had added pre_release so black could be installed with pipenv.

The Solution for me is to remove the flag and to pin the black version.

[dev-packages]
black = "==19.10b0"

or

pipenv install --dev black==19.10b0

With this there is no need to set the pre release option in pipfile. I might come back in a year to check if the maintainers managed to stop abusing the pre release flag.

This doesn't work for me at all.

[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches black==19.10b0,>=19.3b0
[pipenv.exceptions.ResolutionFailure]:       Skipped pre-versions: 18.3a0, 18.3a0, 18.3a1, 18.3a1, 18.3a2, 18.3a2, 18.3a3, 18.3a3, 18.3a4, 18.3a4, 18.4a0, 18.4a0, 18.4a1, 18.4a1, 18.4a2, 18.4a2, 18.4a3, 18.4a3, 18.4a4, 18.4a4, 18.5b0, 18.5b0, 18.5b1, 18.5b1, 18.6b0, 18.6b0, 18.6b1, 18.6b1, 18.6b2, 18.6b2, 18.6b3, 18.6b3, 18.6b4, 18.6b4, 18.9b0, 18.9b0, 19.3b0, 19.3b0, 19.10b0, 19.10b0
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
 Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.

And if you install with --pre it adds allow_prereleases = true to your Pipfile.

[kierun]

Note that using Poetry, you can have:

[tool.poetry.dev-dependencies]
black = "^19.3b0"

However, this does not help the pipenv folks at all…

[dimaqq]

Since this discussion started my team moved black into precommit and we don’t need it in deps at all :)
That’s probably the main strength of black, that it’s so reliable (as in doesn’t break code) that we’re using it as invisible part of the flow “also reformat all modified py files” rather than a test “is this code well-formatted?”

[felix-ht]

Been using black for a long time, and I love it.
I'd like to see a non-prerelease as well. I have to use allow_prereleases = true in Pipfile because of this project, and it causes other projects that are more critical to functionality to pull in prereleases as well.
I'm not saying there's no workaround, but if a project has been out for years now... can it have at least one release please?
One workaround is to pin releases for other dependencies. But one point of the lock file with pipenv is to keep updating your dependencies. That would break a lot less frequently for me if this project had a release.

I just noticed why i was getting beta build for various libs that kept breaking stuff. Turns out someone had added pre_release so black could be installed with pipenv.
The Solution for me is to remove the flag and to pin the black version.

[dev-packages]
black = "==19.10b0"

or
pipenv install --dev black==19.10b0
With this there is no need to set the pre release option in pipfile. I might come back in a year to check if the maintainers managed to stop abusing the pre release flag.

This doesn't work for me at all.

[pipenv.exceptions.ResolutionFailure]:       pipenv.exceptions.ResolutionFailure: ERROR: ERROR: Could not find a version that matches black==19.10b0,>=19.3b0
[pipenv.exceptions.ResolutionFailure]:       Skipped pre-versions: 18.3a0, 18.3a0, 18.3a1, 18.3a1, 18.3a2, 18.3a2, 18.3a3, 18.3a3, 18.3a4, 18.3a4, 18.4a0, 18.4a0, 18.4a1, 18.4a1, 18.4a2, 18.4a2, 18.4a3, 18.4a3, 18.4a4, 18.4a4, 18.5b0, 18.5b0, 18.5b1, 18.5b1, 18.6b0, 18.6b0, 18.6b1, 18.6b1, 18.6b2, 18.6b2, 18.6b3, 18.6b3, 18.6b4, 18.6b4, 18.9b0, 18.9b0, 19.3b0, 19.3b0, 19.10b0, 19.10b0
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
 Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.

And if you install with --pre it adds allow_prereleases = true to your Pipfile.

oteph@oteph-pc:~$ mkdir black_test
oteph@oteph-pc:~$ cd black_test/
oteph@oteph-pc:~/black_test$ pipenv install --dev black==19.10b0
Creating a virtualenv for this project…
Pipfile: /home/oteph/black_test/Pipfile
Using /usr/bin/python3 (3.6.8) to create virtualenv…
⠧ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/oteph/.local/share/virtualenvs/black_test-3N6-Y2Bp/bin/python3
Also creating executable in /home/oteph/.local/share/virtualenvs/black_test-3N6-Y2Bp/bin/python
Installing setuptools, pip, wheel...
done.

✔ Successfully created virtual environment! 
Virtualenv location: /home/oteph/.local/share/virtualenvs/black_test-3N6-Y2Bp
Creating a Pipfile for this project…
Installing black==19.10b0…
Adding black to Pipfile's [dev-packages]…
✔ Installation Succeeded 
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
✔ Success! 
Locking [packages] dependencies…
Updated Pipfile.lock (74ab12)!
Installing dependencies from Pipfile.lock (74ab12)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 8/8 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
oteph@oteph-pc:~/black_test$ cat Pipfile
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
black = "==19.10b0"

[packages]

[requires]
python_version = "3.6"
oteph@oteph-pc:~/black_test$ 

tested with pipenv, version 2018.11.26

seems to work fine on my machine

[ambv]

Hey all,
I'd just like to say I'm sorry for giving a few release dates and then not delivering on this front. This is due to two things. First, I have some probably unreasonable wants for the stable version here. Before I meet them, I would not feel good tagging the release. Second, this is not a paid gig for me and as such it sadly falls into lower priority.

I won't be making a mistake of promising a date anymore but I can tell you this much:

• next week I'm going on a week-long vacation to Malta, which should ideally bring some much needed sunshine into my miserable Polish winter existence;
• after that I will be working hard with the team to finalize the release. I will create a "stable" milestone on GitHub and link issues I consider crucial for inclusion. You'll be able to see how we're doing through that.

Again, sorry for the disappointment. We'll get out of that ditch together.

[mrocklin]

We love you and all you do @ambv ! Enjoy the sun.

[hbmartin]

You're awesome @ambv ! Are there any labels for issues that a newbie to the project can take on?

[lig]

@ambv I'm deeply sorry but there is no stable label on any issue at the moment.

[elreydetoda]

Hey all,
I'd just like to say I'm sorry for giving a few release dates and then not delivering on this front. This is due to two things. First, I have some probably unreasonable wants for the stable version here. Before I meet them, I would not feel good tagging the release. Second, this is not a paid gig for me and as such it sadly falls into lower priority.

I won't be making a mistake of promising a date anymore but I can tell you this much:

• next week I'm going on a week-long vacation to Malta, which should ideally bring some much needed sunshine into my miserable Polish winter existence;
• after that I will be working hard with the team to finalize the release. I will create a "stable" milestone on GitHub and link issues I consider crucial for inclusion. You'll be able to see how we're doing through that.

Again, sorry for the disappointment. We'll get out of that ditch together.

@ambv, would you consider adding a sponsor option? So that way it helps you out and shows how much people appreciate your work in another way than just words. While I am sure it won't pay as much as your current job (probably development, but not going to assume :slightly_smiling_face: ) at least it will be something to help offset your time working on this project. Which thank you for all your continued work over these past two years! I know sticking with projects and tying your name to something is hard! :heart:

[johnthagen]

One way to mitigate the perception risks with a stable release is to specifically instruct people to pin their version of black used in their project.

Prettier is a very popular code formatter for JavaScript/TypeScript and they do just that:

npm install --save-dev --save-exact prettier

This pins the exact version of Prettier in the project's package.json

Later in their docs they explain this clearly:

...because we change how code is formatted in each release! It’s important to have a locked down version of Prettier in your package.json

I think black could take a similar stance and be clear up front that you should pin exact versions, and give examples on how to do this in poetry, pip-tools, pipenv, etc. This then gives black the needed flexibility to evolve and improve without breaking user's projects who are pinning properly.

[ichard26]

If we ever go with that route, we should also recommend folks to lock in their Black configuration in a pyproject.toml file in the case we ever change a default (seems unlikely, but eh).

[mUtterberg]

One way to mitigate the perception risks with a stable release is to specifically instruct people to pin their version of black used in their project.

This is exactly what brought me here. I tried to lock the version of black that I am using with pipenv, but was only able to do so by allowing pre-releases for my entire virtual environment. Would love to be able to pin a 1.0+ and remove the pre-release allowance from my Pipfile.

[Kilo59]

@mUtterberg

https://github.com/psf/black/issues/517#issuecomment-573125735

If for some reason this doesn't work, share your Pipfile.

[lig]

@Kilo59 the problem is that it is not uncommon to have another package with available pre-release in the same Pipfile which is not necessarily necessary to allow installing.

[ambv]

The next episode in this saga has just been released. 20.8b0 is hopefully the last beta. There's many things I wanted to fix before claiming Black is stable but the minimal we need to get in is:

• fix for the currently known issues with formatting instability
• fix stability of --experimental-string-processing

If we can't get the latter stable enough we'll just remove it. But the former is very important to fix.

[ambv]

That first issue is tracked here: https://github.com/psf/black/issues/1629

[intgr]

Sorry if this is the wrong forum, but I just wanted to say 🌟 big thank you 🌟 for the improvements in this release! My experience with Black 19.10b0 was rocky, but 20.8b1 has been perfect so far.

[cooperlees]

Thanks - It's nice to hear this every now and then outside of the usual "why did you change X" and "black should do y" issues. As someone who helps out with black, I appreciate it.

[ichard26]

Glad to hear you've had a great experience with Black! *my goodness I really do sound like a salesman 😅* The common "thanks" in bug reports, feature requests, or design suggestions is usually nice... but yeah hearing a "Thank you!" without strings attached definitely lifts up my mood a bit as maintainers[1] typically don't hear it often.

[1]. Technically I am *not* a maintainer but a triager, but I like to think I also help out with Black 😉

Thanks, but let's also not forget about the many outside contributors to Black 😃

[elreydetoda]

Hey all,
I'd just like to say I'm sorry for giving a few release dates and then not delivering on this front. This is due to two things. First, I have some probably unreasonable wants for the stable version here. Before I meet them, I would not feel good tagging the release. Second, this is not a paid gig for me and as such it sadly falls into lower priority.
I won't be making a mistake of promising a date anymore but I can tell you this much:

• next week I'm going on a week-long vacation to Malta, which should ideally bring some much needed sunshine into my miserable Polish winter existence;
• after that I will be working hard with the team to finalize the release. I will create a "stable" milestone on GitHub and link issues I consider crucial for inclusion. You'll be able to see how we're doing through that.

Again, sorry for the disappointment. We'll get out of that ditch together.

@ambv, would you consider adding a sponsor option? So that way it helps you out and shows how much people appreciate your work in another way than just words. While I am sure it won't pay as much as your current job (probably development, but not going to assume slightly_smiling_face ) at least it will be something to help offset your time working on this project. Which thank you for all your continued work over these past two years! I know sticking with projects and tying your name to something is hard! heart

Hey @ambv, that is awesome news!!! Thank you for all of your and the teams hard work!!

I was curious though, any chance I will get a response to my question above :arrow_up: ? I want to try and help with the only way I have time to do, and that is to try and help sponsor the project. I know it won't be very much, but something like a patreon with different tiers of support so that people whom can't help by coding (either because of time or expertise) can support this awesome project in a different way than code?

[ambv]

PLEASE CAN YOU JUST RELEASE THE FLIPPING TOOL??!?

Did you expect this sort of message to be effective? You're a random anonymous stranger, coming to my issue tracker to yell at me because you don't like how a free tool's development is managed.

My advice, and this is coming straight from the heart, is: go away.

[thomasf]

We are all using it in production anyway, you are not preventing any pain, but causing it.

Not me, I won't add it to any lage projects CI until there is a release version. I still only rely on flake8+isort to do CI linting, some team members use black and some use other formatting tools but it will definitely not be dictated until a stable black version exists.

An external example: Django will adopt black but not until a release version that won't change formatting is available. ( https://github.com/django/deps/blob/master/accepted/0008-black.rst#timeline )

If it's so important to you, just clone the source, change the version number and upload it to pypi under a different name and you are done. It literally takes a few minutes to do that.

[ambv]

I also came here to offer some advice

Oh please. Your "advice" uses all caps, excessive numbers of exclamation marks and question marks, calls our struggle a joke, and is factually incorrect (the tool you're claiming is "good for every user" has 315 open issues at the time I'm writing this comment).

Quite a feat for such a short comment from an anonymous person who offered no help beyond unsolicited "advice". Continuing this conversation is in fact the opposite of help, escalating negative emotions and noise on an already busy issue tracker.

[max-sixty]

Without wanting to add a comment telling the maintainers what to do — could I suggest the spammy comments are marked as spam, rather than engaged with?

[timothycrosley]

There are many benefits to being careful and methodical when building out a tool as ambitious as Black. As just one example, this care has enabled other commonly used libraries in the Python linting and formatting space to ensure they are fully compatible with Black. Black's conservative release approach has given projects time to do this proactively instead of retroactively. I aspire to the level of discipline and care that @ambv and others who work on this project have taken. I don't follow many projects, but I follow Black as it is a constant source of inspiration for how I can better maintain and contribute to OSS projects.

[JelleZijlstra]

Answering @elreydetoda's question from above: I think the best way to help get Black to a stable state really is to get bugs fixed, either by writing the code yourself or by helping get the word out so people who are interested in writing code can find us.

I'd recommend starting with the issues in unstable formatting and invalid code, because those tend to be more straightforward (there's a clear repro case, and clearly wrong behavior). Ideally, stable Black won't have any known crashes. As a maintainer, I'd love to review PRs fixing all of these crashes.

[ankostis]

(my apologies for being too late in the party)
Maybe the issue with pipenv wouldn't exist if black's version identifier was PEP440 compatible, with 3 parts (major, minor, build),
AND the major was 0.
If i remember correctly, pip installs just fine pre (non-stable) dependencies that have versions like 0.1.2a1,
which makes sense: black is at exactly this spot, without having any stable release since its inception,
but still being worked on, many projects downstream have come to depend on it.

So in a nutshell, would you consider to switch to a PEP440 version identifier with the next release,
using a new "epoch" like this: 2!0.20.8b2?

[astrojuanlu]

@ambv has stated his very clear conditions to make a stable black release. Many of us subscribed to this issue to hear updates from the Black development team about progress on those conditions. @JelleZijlstra has stated above "the best way to help get Black to a stable state really is to get bugs fixed, either by writing the code yourself or by helping get the word out so people who are interested in writing code can find us". Please keep this thread informative and, if you want to help, make yourself useful in the ways the developers have kindly encouraged us all to do so.

[henryiii]

@ambv If it makes you feel any better, NumPy has 1.9k issues and is good for lots of users. :) The number of issues is more indicative of the level of use than it is of the quality of the library. Bad bugs (like #1629) are what matter.

Also, clang-format changes sometimes between releases and is _much_ harder to pin than a Python library. ;)

[hadialqattan]

Please see: #1746