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

Open
lig opened this issue Sep 18, 2018 · 35 comments

Comments

@lig
Copy link

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

commented Nov 27, 2018

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

@ambv

This comment has been minimized.

Copy link
Collaborator

commented Nov 27, 2018

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

@Aareon

This comment has been minimized.

Copy link

commented Dec 23, 2018

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

@massenz

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Author

commented Dec 25, 2018

@ambv Merry Christmas!:)

@dimaqq

This comment has been minimized.

Copy link

commented Jan 16, 2019

Please? 🙏

acdha added a commit to LibraryOfCongress/concordia that referenced this issue Jan 22, 2019
Remove allow_prereleases=true from Pipfile
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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Feb 11, 2019

@ambv Friendly ping. 😇

@fernandezpablo85

This comment has been minimized.

Copy link

commented Mar 7, 2019

@ambv friendlier ping

@max-wittig

This comment has been minimized.

Copy link

commented Mar 19, 2019

@ambv even friendlier ping :P

@hugovk

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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 :)

@jxltom jxltom referenced this issue Mar 27, 2019
17 of 18 tasks complete
@tribals

This comment has been minimized.

Copy link

commented Apr 17, 2019

Any changes on this?

@zsol

This comment has been minimized.

Copy link
Collaborator

commented Apr 17, 2019

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

@ambv

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link

commented Jun 4, 2019

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

@illfated illfated referenced this issue Jun 4, 2019
@Imaclean74

This comment has been minimized.

Copy link

commented Jul 10, 2019

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

@dvf

This comment has been minimized.

Copy link

commented Jul 21, 2019

It’s time 🙏

@fernandezpablo85

This comment has been minimized.

Copy link

commented Jul 21, 2019

@ambv ?

@Juanlu001

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

Screenshot_2019-07-23 black

@ambv

This comment has been minimized.

Copy link
Collaborator

commented Jul 23, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 23, 2019

@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

This comment has been minimized.

Copy link

commented Jul 28, 2019

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

This comment has been minimized.

Copy link

commented Aug 8, 2019

@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

This comment has been minimized.

Copy link

commented Aug 8, 2019

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

This comment has been minimized.

Copy link

commented Aug 8, 2019

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

This comment has been minimized.

Copy link

commented Aug 8, 2019

@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

This comment has been minimized.

Copy link

commented Aug 8, 2019

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

@dimaqq

This comment has been minimized.

Copy link

commented Aug 9, 2019

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

This comment has been minimized.

Copy link

commented Aug 20, 2019

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

This comment has been minimized.

Copy link

commented Sep 13, 2019

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

This comment has been minimized.

Copy link

commented Sep 13, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.