Hi@kidkoder432 - while we wait for a proper review, would you mind taking a look at the Linting failure here?https://github.com/matplotlib/matplotlib/actions/runs/5780696475/job/15664707497?pr=26462

It looks like you are missing a blank line in your test.

This change has caused some test failures.@kidkoder432 are you confident to investigate those yourself? You can see the full output from the tests by clicking the "Details" link by one of the checks at the bottom of this page. You can also run the tests yourself locally:
https://matplotlib.org/devdocs/devel/testing.html

This change has caused some test failures.@kidkoder432 are you confident to investigate those yourself? You can see the full output from the tests by clicking the "Details" link by one of the checks at the bottom of this page. You can also run the tests yourself locally:https://matplotlib.org/devdocs/devel/testing.html

Sure, I'll take a look and let you know any concerns.

Edit: I fixed theNoneType errors that were occurring when amedianprops dictionary was not provided, but those same tests now fail withImageComparisonFailure:

Okay, so I looked at the failing tests and noticed that the expected images were all using a capstyle ofprojecting. However, because I modified the code to use a capstyle ofbutt. the original tests for median lines were failing because they were expecting aprojecting capstyle. However, this capstyle is the reason why the median line was extending past the box. According to thedocs:

'projecting'
the line is squared off as inbutt, but the filled-in area extends beyond the endpoint a distance oflinewidth/2.

I'm not sure how to move forward with this.

OK, if the user specifies a capstyle then we should assume they are happy with their choice and leave it. We should only set it to “butt” if the user didn’t make a choice. I think the dictionarysetdefault method might be useful here.

OK, if the user specifies a capstyle then we should assume they are happy with their choice and leave it. We should only set it to “butt” if the user didn’t make a choice. I think the dictionarysetdefault method might be useful here.

Good idea.
Those tests don't seem to define a capstyle specifically though, so they still fail...

Ah OK, I thought you meant that some tests were specifying “projecting” as the capstyle. Instead they are just leaving it to default and this change switches the default from “projecting” to “butt”. So the tests are failing because of a genuine (desired) change in the output, which means you will need to replace the reference images. We have thetriage_tests tool to help with that.

Thanks for the update@kidkoder432. It looks like you still have a couple of image test failures for pdf files. Do you see those failures locally? If not you might be missing a dependency - most likely ghostscript.
https://matplotlib.org/devdocs/devel/dependencies.html#dependencies-for-testing-matplotlib

I think thetriage_tests script should handle pdf as well as png.

I'm having trouble getting pytest to recognize that I have Ghostscript installed. are there any resources for this on the matplotlib docs?

i used the installer to install Ghostscript 10.01.2.

Matplotlib only interacts with ghostscript via subprocess calls. Can you callgs as a CLI program (e.g.gs --help) (on windows it may also be calledgswin64c, not really sure what is fully going on there...)

If it is not in your PATH, it will not be found, so make sure it is installed in a place that it can be executed.

Hi, for some reason it says that CodeCov tests failed in the workflow logs. However, when I visit the website, its says that codecov tests all passed. Can someone please take a look at this?

I wouldn’t worry about that codecov failure. We currently use codecovfor information only. In this case, codecov says that 100% of your change is covered, which I think is the important thing. The coverage reductions are all “indirect changes” - I haven’t really got my head around how those are caused myself.

Question: Does anybody understand why the box borders are sometimes shifted slightly?

Comment: The original issue also discussed bringing the line below the box using zorder. This is not discussed in this PR, While conceptually desireable, this is not so easy to fix: The box can be filled and then face and edge are drawn with the same zorder. This means, one cannot draw mean/median lines below the box edge but above the box face (at least not without complicating the draw logic).
I'm therefore inclinded to accept the PR without addressing zorder, but would like to have at least one second thought on this.

Not sure why either... From what you explained about the draw logic it would likely be much easier to stay with the current implementation.

Question: Does anybody understand why the box borders are sometimes shifted slightly?

Do you have an example? When I looked at the test images that have changed here, all the diffs seemed to just show the median line getting shorter.

I'm therefore inclinded to accept the PR without addressing zorder, but would like to have at least one second thought on this.

I came to same conclusion based on@oscargus' comment on the previous PR:#23335 (comment)

Do you have an example? When I looked at the test images that have changed here, all the diffs seemed to just show the median line getting shorter.

Can't find anymore. Either I was wrong or this was somehow fixed through the recent updates.

Since this is a bugfix, I recon that it can still go into 3.8.0 (on the basis that we do not have release candidates for any bugfix releases, there's no difference between deferring to 3.8.1 and pushing this into 3.8.0 even after 3.8.0rc1).

Thanks@kidkoder432, and congratulations on your first contrbution to matplotlib! We'd happy to see you back!