Closed tevansuk closed 5 years ago
Sounds like this is worth reporting to pipenv as a bug? Surely black==19.3b0,>=19.3b0 is solved as 19.3b0
Also worth nudging black for that overdue release...
If I changed the flake8-black dependency to == it would solve this, but make trouble once there is a newer black release.
It’s perhaps possible to recreate a backwards compatible hack for older versions of black, but my recent refactoring to cache any parsed configuration makes that a bit harder than it used to be.
I don't think pipenv has a bug here, when we say "black>=19.3b0" this is asking for a release that is greater than 19.3b0, of which there are none. I do think the correct thing to do for flake8-black
is to specify ==19.3b0
because a future release of black may have changes that "break" compared to 19.3b0
. Anticipated breaking changes is actually why there is not an actual release of black yet. If flake8-black
requires 19.3b0
it should probably specify that explicitly.
For now, we have fixed flake8-black==0.1.0
, which feels slightly wrong to me.
Pushing black for a proper release is probably counter-productive, many people already have and more noise just stops them from getting the things done that they want to do before making an actual release (see https://github.com/psf/black/issues/517 , every few weeks it is prompted for!)
Reading black issue 517, I agree further noise won't do any good (although a few more thumbs up wouldn't hurt). From that discussion it sounds like installing black==19.3b0 explicitly, possibly prior to the other dependencies, is a workaround?
black = "==19.3b0"
There is https://github.com/pypa/pipenv/issues/1760 but perhaps you should open a new pipenv
issue for this particular problem?
Where you said:
This makes pipenv look for the latest released version of black to install... except there is no latest release that is not a pre-release!
This comment seems directly relevant, https://github.com/pypa/pipenv/issues/1760#issuecomment-527366599
Just noting that
pipenv
isn't currently abiding by one of the usability recommendations that was included in the PEP 440 specification. Specifically: "By default, dependency resolutions tools SHOULD ... accept remotely available pre-releases for version specifiers where there is no final or post release that satisfies the version specifier"
This does to me seem like a problem in pipenv
.
Problem with such a great tool as pipenv, I assumed that it was following PEP-440 :) Happy to close this and follow it up with pipenv.
Fingers crossed for a pipenv
solution.
Looking at the error message again, I doubt changing the flake8-black
dependency to black==19.3b0
would help? Probably the only fix on my side would be to get the plugin to work with any recent release of black (possible, but not straightforward or elegant given the recent changes I made).
Use: pipenv install --pre
@atwoodjw using --pre
flag will apply across ALL packages, not just the specific package, which can have negative results.
Fixed via #22 (a good compromise now that the minimum version of black we need is over a year old)
Some slight problems with the 0.1.1 release when using with pipenv. Because black does not yet have a "stable" release (unbelievably, its been coming "in a few weeks" for about 18 months now!), every single release of black must be installed with
--pre
flag with pipenv, unless an exact version match is specified.However, with the 0.1.1 release of flake8-black, we've got two specifiers for black specified - "==19.3b0" from the project, and ">=19.3b0" from flake8-black. This makes pipenv look for the latest released version of black to install... except there is no latest release that is not a pre-release!
This is then double complicated by pipenv. There is no "--pre" flag for pipenv that applies just to a single package, so now in order to get a lock, we must allow all pre-release packages to be considered by pipenv. This is not ideal!