Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-prerelease black release #517

Closed
lig opened this issue Sep 18, 2018 · 113 comments · Fixed by #2529
Closed

Non-prerelease black release #517

lig opened this issue Sep 18, 2018 · 113 comments · Fixed by #2529
Labels
C: maintenance C: packaging

Comments

@lig
Copy link

lig commented Sep 18, 2018

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
Copy link
Collaborator

ambv commented Sep 18, 2018

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

@gforcada
Copy link

gforcada commented Nov 27, 2018

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

@ambv
Copy link
Collaborator

ambv commented Nov 27, 2018

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

@Aareon
Copy link

Aareon commented Dec 23, 2018

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

@massenz
Copy link

massenz commented Dec 24, 2018

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
Copy link

Aareon commented Dec 25, 2018

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
Copy link
Author

lig commented Dec 25, 2018

@ambv Merry Christmas!:)

@dimaqq
Copy link

dimaqq commented Jan 16, 2019

Please? 🙏

acdha added a commit to LibraryOfCongress/concordia that referenced this issue Jan 22, 2019
This avoids `piping update` allowing packages
other than Black to be installed from pre-release
candidates prior to either one of these issues
being resolved:

pypa/pipenv#1760
psf/black#517

This commit back-levels pyyaml to the last release
along with the coverage developer tool and locks
all current non-major updates.
@dyve
Copy link

dyve commented Jan 23, 2019

See also
alanhamlett/pip-update-requirements#23 (comment)

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

A non-beta version would be much appreciated.

@Utsav2
Copy link
Contributor

Utsav2 commented Feb 4, 2019

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
Copy link

Peque commented Feb 11, 2019

@ambv Friendly ping. 😇

@fernandezpablo85
Copy link

fernandezpablo85 commented Mar 7, 2019

@ambv friendlier ping

@max-wittig
Copy link

max-wittig commented Mar 19, 2019

@ambv even friendlier ping :P

@hugovk
Copy link
Contributor

hugovk commented Mar 19, 2019

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
Copy link

dimaqq commented Mar 20, 2019

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

@tribals
Copy link

tribals commented Apr 17, 2019

Any changes on this?

@zsol
Copy link
Collaborator

zsol commented Apr 17, 2019

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

@JelleZijlstra JelleZijlstra added the C: packaging label May 5, 2019
@ambv
Copy link
Collaborator

ambv commented May 7, 2019

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

@max-wittig
Copy link

max-wittig commented Jun 4, 2019

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

@lig
Copy link
Author

lig commented Oct 21, 2021

@WimYedema right. That is exactly what is happening;) Black is already the standard format for Python code in an enormous amount of projects. Black is more stable and usable than some libraries in Python's stdlib. I even changed a laptop and restored my Black sticker on a new one already. And still, we have it in a "pre-release" stage.
I'm starting to think that Black will be a legendary Python package that will never go out of a pre-release just for the sake of it.

P.S.: this issue is 3 years old already BTW...

@astrojuanlu
Copy link
Contributor

astrojuanlu commented Oct 21, 2021

I think I am addicted to the comments on this issue. The maintainers have repeatedly stated their point of view, and yet people keep begging (begging!) that black releases a stable version (clearly showing that they have not read such pronouncements) while acknowledging that they're using it regardless. Or, alternatively, they complain here that Pipenv can't handle beta packages correctly, which is hardly a black issue and more of a Pipenv issue.

Three years of useless ramblings and crazy ideas only for folks to stop seeing a teeny-weeny chr(98) letter at the end of the version string, as if this is going to bring world peace, end world hunger, and convince humans to stop putting pineapple on pizza!

Black maintainers: please never ever release a stable version. Keep the charade on. Not even in the face of Armaggedon. Never compromise.

ambv pushed a commit that referenced this issue Oct 21, 2021
Fixes #2394. Eventually fixes #517.

This is essentially @pradyunsg's suggestion from #2394. I suggest that at the
same time we start the formal stability policy, we take a few other disruptive steps
and drop Python 2 and the "b" marker.
Stable release automation moved this from To Do to Done Oct 21, 2021
ambv added a commit that referenced this issue Oct 21, 2021
Fixes #2394. Eventually fixes #517.

This is essentially @pradyunsg's suggestion from #2394. I suggest that at the
same time we start the formal stability policy, we take a few other disruptive steps
and drop Python 2 and the "b" marker.

Co-authored-by: Pradyun Gedam <pradyunsg@gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
@lig
Copy link
Author

lig commented Oct 21, 2021

@ambv please, reopen this one.

I believe it has been closed because of Eventually fixes #517. in #2529.

1 similar comment
@lig
Copy link
Author

lig commented Oct 21, 2021

@ambv please, reopen this one.

I believe it has been closed because of Eventually fixes #517. in #2529.

@ichard26 ichard26 reopened this Oct 21, 2021
Stable release automation moved this from Done to To Do Oct 21, 2021
JelleZijlstra added a commit that referenced this issue Nov 16, 2021
Fixes #2394. Eventually fixes #517.

This is essentially @pradyunsg's suggestion from #2394. I suggest that at the
same time we start the formal stability policy, we take a few other disruptive steps
and drop Python 2 and the "b" marker.

Co-authored-by: Pradyun Gedam <pradyunsg@gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
@gsemet
Copy link

gsemet commented Nov 25, 2021

Hi. I have read and reread again this thread and I still do not understand why a non-prerelease version of black has not been released yet.
At least provide the option to the user. Keep "black" as it is but provide a "black-stable" package that allow your beloved users to not force version or allow_prerelease for package.

I use poetry, so this is not a problem for me. But I do not see why black would behave differently than any other python package (release... Pull Request... release.... and over and over).

@dimaqq
Copy link

dimaqq commented Nov 25, 2021

@gsemet please release it to PYPI. call it gray or whatever 🖤

@hugovk
Copy link
Contributor

hugovk commented Nov 25, 2021

https://pypi.org/project/gray/, https://pypi.org/project/grey/, https://pypi.org/project/blue/, https://pypi.org/project/tan/ and https://pypi.org/project/white/ already exist :)

@dimaqq
Copy link

dimaqq commented Nov 25, 2021

Someone even made https://pypi.org/project/blacker/ which is black at some old version 😅

blackish is still free though!

@felix-hilden
Copy link
Collaborator

felix-hilden commented Nov 25, 2021

We appreciate the enthusiasm, but please note that we have defined a stability policy (#2394) and are planning a stable release. Any news will be announced here. In the meantime though, further comments don't really make the cogs turn any faster.

@dyve
Copy link

dyve commented Nov 25, 2021

We appreciate the enthusiasm, but please note that we have defined a stability policy (#2394) and are planning a stable release. Any news will be announced here. In the meantime though, further comments don't really make the cogs turn any faster.

Agreed. No black humor please.

@gsemet
Copy link

gsemet commented Nov 25, 2021

https://pypi.org/project/blacker/

That's an option:

  • get a pipeline triggered on any new version of package black
  • convert the version XX.M.bP to XX.0M.P and rebuild the same package named black-let-It-go

@psf psf locked as resolved and limited conversation to collaborators Nov 25, 2021
@ichard26 ichard26 moved this from To Do (nice to have) to To Do (critical) in Stable release Jan 1, 2022
@psf psf unlocked this conversation Jan 29, 2022
@felix-hilden
Copy link
Collaborator

felix-hilden commented Jan 29, 2022

I'm pleased to announce that Black is finally non-beta software! 🎉 Here's the full changelog!

Going forward we'll follow our stability policy. Work continues as usual with bugfixes and enhancements, but style changes are now introduced under our new --preview CLI switch. This allows us to evolve Black's style without too much disruption to users that want consistency. The default style is updated yearly.

Thanks to our maintainers for orchestrating the efforts, especially to our most recent reinforcement Batuhan (@isidentical) who was responsible for our match statement support! A hearty thank you to all of our contributors for pushing Black forward, and to our users for being the reason we do it!

Thanks for sticking with us, it's time to close this issue!

Stable release automation moved this from To Do (important) to Done Jan 29, 2022
@ambv
Copy link
Collaborator

ambv commented Jan 29, 2022

im-not-crying

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: maintenance C: packaging
Projects
No open projects
Development

Successfully merging a pull request may close this issue.