Release v2.2.3

[wjakob]

Hi all,

Given that PIP 10 breaks the pybind11 include file finding routine (issue #1174), I propose that we push out a v2.2.3 patch release soon. Are there any other urgent things that should be merged?

Thanks,
Wenzel

cc @jagerman

[Froskekongen]

I think the pip 10 issue is causing a lot of red builds around. I would appreciate a 2.2.3 release asap, to avoid having to hack the pipenv virtualenv (:

[jbarlow83]

I suggest releasing 2.2.3 as just "2.2.2 + cherrypicked pip10 patch" so people can fix their builds easily without having to deal with fallout from other changes.

[jagerman]

Take a look at the 2.2.3 milestone; we should definitely include the three closed PRs, and either quickly decide on the other two or punt them off to 2.2.4/2.3.

I suggest releasing 2.2.3 as just "2.2.2 + cherrypicked pip10 patch" so people can fix their builds easily without having to deal with fallout from other changes.

Indeed; I generally only tag things for a patch release if it fixes something; feature changes have to wait for the next minor version (2.3.0).

[MohammadChavosh]

Thanks a lot for the maintenance. Just to know, approximately when the pip10 compatible version will be available for installing via pip?

Thanks.

[trelau]

I would love to get #1353 in v2.2.3 if it makes sense but I could use some help answering #1353 (comment).

[jbarlow83]

I'd like to point out that pip 9 aggressively auto-updates itself to pip 10 at every opportunity unless it's explicitly told to hold back, so uptake of pip 10 should be happening quickly. You have to enter something like pip install --upgrade mypackage 'pip < 10' every time you do something in pip, to tell pip 9 to hold back.

pip also ignores a setup.py directive to avoid version 10 (install_requires=['pip < 10']) and will update or attempt installation with 10 anyway. So there's no workaround for a package to declare itself dependent on pip 9. I hope this underscores the urgency.

My review of the proposed milestone 2.2.3 changes:

• Detect pybind11 header path without depending on pip internals (fixes #1174) #1190 is the urgent fix needed for pip

• Fix numpy dtypes test on big-endian architectures #1287 looks innocent enough to include safely

• Add workaround for clang 3.3/3.4 #1350 looks good to me

• Enable unique_ptr holder with mixed Deleters between base and derived types #1353 has an open question and is over my head; punt

• Enforces intel icpc >= 2017, fixes #1121 #1363 (same as alias template error with Intel 2016.0.3 compilers #1121) looks simple, but fails CI, probably the CI's fault; punt to be safe

[loriab]

I've already put the check in my project, so I've no personal urgency on #1363/#1121. But there's only one character of substantive code change in the PR, and it only affects intel compilers (which are no where near CI), and other PRs show the same failure pattern. So do what you like, but I'm pretty sure it's safe. :-)

[bstaletic]

#1363 didn't build because of the pip 10 nonsense. Once it is rebased on top of master it should pass.

[loriab]

Thanks, @bstaletic, #1363 is healed.

[wjakob]

Hey all,

I've pushed out v2.2.3 with everything except #1353. Sorry that it took me a bit to get to this.

Best,
Wenzel

[trelau]

Thanks for update @wjakob Do you expect to accept #1353 in the future? I'm updating a binding generator tool and that PR removes a lot of boilerplate code, but I can make it work either way, so just wondering if perhaps I should support both.

[wjakob]

Hi @trelau,
that patch generally seems reasonable to me. I did not merge it yet since it looked like there was an unconverged discussion with @EricCousineau-TRI. I'm happy to merge it (and pull into 2.2.4) once this is resolved.
Best,
Wenzel

[trelau]

@wjakob great, thank you for the update.

[EricCousineau-TRI]

Sorry, didn't mean to slow that down! I will briefly test out that feature branch and see if there are any issues with mixed holder types along inheritance, or if I got confused with some other PRs; will follow-up on that issue.

[jbarlow83]

Thanks everyone, especially @jagerman for your hard work on this.