From j.p.mitrevski at gmail.com Sun May 3 14:51:17 2020 From: j.p.mitrevski at gmail.com (Jovan Mitrevski) Date: Sun, 3 May 2020 13:51:17 -0500 Subject: [Matplotlib-devel] QtQuick backend development Message-ID: <857785ac-f291-c2bd-e1a6-bef9a2d58305@gmail.com> Hi, For a project I am working on I created an updated QtQuick backend, originally starting from the old matplotlib_qtquick_playground. The current version largely consists of: https://github.com/jmitrevs/matplotlib/blob/qtquick5/lib/matplotlib/backends/backend_qtquick.py https://github.com/jmitrevs/matplotlib/blob/qtquick5/lib/matplotlib/backends/backend_qtquickagg.py and some minor changes, for example in qt_compat.py and such. At the moment it doesn't work as a backend you can select and have a window open, since I only use it from inside a QtQuick-based application. Is there interest in me trying to get this in shape for inclusion in matplotlib, or should I continue keeping it separate for my own use only? Jovan From anntzer.lee at gmail.com Sun May 3 16:35:45 2020 From: anntzer.lee at gmail.com (Antony Lee) Date: Sun, 3 May 2020 22:35:45 +0200 Subject: [Matplotlib-devel] ANN: mplcairo 0.3 release Message-ID: Dear all, I am pleased to announce the release of mplcairo 0.3. mplcairo is a Matplotlib backend based on the well-known cairo library, supporting output to both raster (including interactively) and vector formats. In other words, it provides the functionality of Matplotlib's {,qt5,gtk3,wx,tk,macos}{agg,cairo}, pdf, ps, and svg backends. Per Matplotlib's standard API, the backend can be selected by calling matplotlib.use("module://mplcairo.qt") or setting your MPLBACKEND environment variable to `module://mplcairo.qt` for Qt5, and similarly for other toolkits. mplcairo 0.3 adds support for OpenType font features (see `examples/opentype_features.py`), pdftex.map font effects, simplifications to the build, and as well as the usual bugfixes over 0.2. Enjoy, Antony Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.p.mitrevski at gmail.com Sun May 3 20:02:58 2020 From: j.p.mitrevski at gmail.com (Jovan Mitrevski) Date: Sun, 3 May 2020 19:02:58 -0500 Subject: [Matplotlib-devel] QtQuick backend development Message-ID: <17b0dcea-db8a-1a1a-40df-5c3853f68409@gmail.com> Hi, Actually I put the qtquick backend in a separate package for now: https://pypi.org/project/matplotlib-backend-qtquick/ That might be the best way to do this. Anyway, I am not an expert in either matplotlib or Qt, just a user, so please give me any recommendations if you have them. Jovan From anntzer.lee at gmail.com Mon May 4 02:28:39 2020 From: anntzer.lee at gmail.com (Antony Lee) Date: Mon, 4 May 2020 08:28:39 +0200 Subject: [Matplotlib-devel] QtQuick backend development In-Reply-To: <17b0dcea-db8a-1a1a-40df-5c3853f68409@gmail.com> References: <17b0dcea-db8a-1a1a-40df-5c3853f68409@gmail.com> Message-ID: Hi, I don't know much (or anything) about qtquick, but am reasonably familiar with the qt5 backend. It looks like there's a decent amount of duplication between the two backends; I guess it may be possible to merge the two with a relatively small amount of changes to the qt5 backend? in which case this would be reasonable. Especially if this is only intended for embedded use (I guess pyplot wouldn't make much sense?), so you just need to expose the canvas and toolbar classes. Cheers, Antony On Mon, May 4, 2020 at 2:03 AM Jovan Mitrevski wrote: > Hi, > > Actually I put the qtquick backend in a separate package for now: > > https://pypi.org/project/matplotlib-backend-qtquick/ > > That might be the best way to do this. Anyway, I am not an expert in > either matplotlib or Qt, just a user, so please give me any > recommendations if you have them. > > Jovan > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Tue May 5 21:55:31 2020 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 5 May 2020 15:55:31 -1000 Subject: [Matplotlib-devel] Why keep codecov? Message-ID: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> https://codecov.io/gh/matplotlib/matplotlib/compare/5455bab77e75cee46d260c0f27110d6b4fa78270...3eb471dadd2fd397c840bc98db90a06845697131/changes The link above is what I find for the "failing" codecov test for https://github.com/matplotlib/matplotlib/pull/17266, which is passing all the other tests. The codecov.io output looks like complete garbage, listing a huge number of untouched files. I added 2 tests for the code I modified. As far as I can see, from a practical standpoint, codecov is incorrectly flagging the PR as failing, leading to a misleading red X in the PR list. I can see how a mechanized code coverage test could be useful for a project at an early stage, when it is building up its test infrastructure, and at a later stage, to be run occasionally, especially when major code additions are made. As it is being run now, however, I think it is impeding, not aiding, the development process. I recommend that we remove it from the suite of tests run for every PR, or at least keep it out of the accounting for the overall "pass/fail" rating of the PR. Eric From jklymak at uvic.ca Tue May 5 22:48:15 2020 From: jklymak at uvic.ca (Jody Klymak) Date: Tue, 5 May 2020 19:48:15 -0700 Subject: [Matplotlib-devel] Why keep codecov? In-Reply-To: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> References: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> Message-ID: Hi Eric, I agree for the codecov/project check. I don?t see how it helps, and I routinely ignore it during reviews because it is pretty obscure how you are supposed to fix it. In my opinion, codecov/patch is pretty helpful to know if someone?s new code actually ever gets exercised. Cheers, Jody > On May 5, 2020, at 18:55 PM, Eric Firing wrote: > > https://codecov.io/gh/matplotlib/matplotlib/compare/5455bab77e75cee46d260c0f27110d6b4fa78270...3eb471dadd2fd397c840bc98db90a06845697131/changes > > The link above is what I find for the "failing" codecov test for https://github.com/matplotlib/matplotlib/pull/17266, which is passing all the other tests. > > The codecov.io output looks like complete garbage, listing a huge number of untouched files. > > I added 2 tests for the code I modified. As far as I can see, from a practical standpoint, codecov is incorrectly flagging the PR as failing, leading to a misleading red X in the PR list. > > I can see how a mechanized code coverage test could be useful for a project at an early stage, when it is building up its test infrastructure, and at a later stage, to be run occasionally, especially when major code additions are made. > > As it is being run now, however, I think it is impeding, not aiding, the development process. > > I recommend that we remove it from the suite of tests run for every PR, or at least keep it out of the accounting for the overall "pass/fail" rating of the PR. > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel From tcaswell at gmail.com Tue May 5 23:24:16 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 5 May 2020 23:24:16 -0400 Subject: [Matplotlib-devel] Why keep codecov? In-Reply-To: References: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> Message-ID: I think the current problem with codecov is that on the master branch azure uploads coverage reports but it does not an the PR runs which leads to the drop in coverage due to the edge cases that are hit slightly differently on azure than on travis / appveyor. Tom On Tue, May 5, 2020 at 11:21 PM Jody Klymak wrote: > Hi Eric, > > I agree for the codecov/project check. I don?t see how it helps, and I > routinely ignore it during reviews because it is pretty obscure how you are > supposed to fix it. > > In my opinion, codecov/patch is pretty helpful to know if someone?s new > code actually ever gets exercised. > > Cheers, Jody > > > On May 5, 2020, at 18:55 PM, Eric Firing wrote: > > > > > https://codecov.io/gh/matplotlib/matplotlib/compare/5455bab77e75cee46d260c0f27110d6b4fa78270...3eb471dadd2fd397c840bc98db90a06845697131/changes > > > > The link above is what I find for the "failing" codecov test for > https://github.com/matplotlib/matplotlib/pull/17266, which is passing all > the other tests. > > > > The codecov.io output looks like complete garbage, listing a huge > number of untouched files. > > > > I added 2 tests for the code I modified. As far as I can see, from a > practical standpoint, codecov is incorrectly flagging the PR as failing, > leading to a misleading red X in the PR list. > > > > I can see how a mechanized code coverage test could be useful for a > project at an early stage, when it is building up its test infrastructure, > and at a later stage, to be run occasionally, especially when major code > additions are made. > > > > As it is being run now, however, I think it is impeding, not aiding, the > development process. > > > > I recommend that we remove it from the suite of tests run for every PR, > or at least keep it out of the accounting for the overall "pass/fail" > rating of the PR. > > > > Eric > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Wed May 6 02:37:42 2020 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 5 May 2020 20:37:42 -1000 Subject: [Matplotlib-devel] Why keep codecov? In-Reply-To: References: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> Message-ID: Tom, I'm sorry but I don't understand. Let me put it another way: how often does the codecov flagging and output lead to the discovery and solution of a real problem? At present, it is clearly an annoyance that incurs a real penalty by putting false information into the PR listings; if that isn't balanced by some substantial benefit, then we should drop it. What am I missing? Eric On 2020/05/05 5:24 PM, Thomas Caswell wrote: > I think the current problem with codecov is that on the master branch > azure uploads coverage reports but it does not an the PR runs which > leads to the drop in coverage due to the edge cases that are hit > slightly differently on azure than on travis / appveyor. > > Tom > > On Tue, May 5, 2020 at 11:21 PM Jody Klymak > wrote: > > Hi Eric, > > I agree for the codecov/project check.? I don?t see how it helps, > and I routinely ignore it during reviews because it is pretty > obscure how you are supposed to fix it. > > In my opinion, codecov/patch is pretty helpful to know if someone?s > new code actually ever gets exercised. > > Cheers,? ?Jody > > > On May 5, 2020, at? 18:55 PM, Eric Firing > wrote: > > > > > https://codecov.io/gh/matplotlib/matplotlib/compare/5455bab77e75cee46d260c0f27110d6b4fa78270...3eb471dadd2fd397c840bc98db90a06845697131/changes > > > > The link above is what I find for the "failing" codecov test for > https://github.com/matplotlib/matplotlib/pull/17266, which is > passing all the other tests. > > > > The codecov.io output looks like complete > garbage, listing a huge number of untouched files. > > > > I added 2 tests for the code I modified.? As far as I can see, > from a practical standpoint, codecov is incorrectly flagging the PR > as failing, leading to a misleading red X in the PR list. > > > > I can see how a mechanized code coverage test could be useful for > a project at an early stage, when it is building up its test > infrastructure, and at a later stage, to be run occasionally, > especially when major code additions are made. > > > > As it is being run now, however, I think it is impeding, not > aiding, the development process. > > > > I recommend that we remove it from the suite of tests run for > every PR, or at least keep it out of the accounting for the overall > "pass/fail" rating of the PR. > > > > Eric > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > -- > Thomas Caswell > tcaswell at gmail.com From tcaswell at gmail.com Wed May 6 11:10:37 2020 From: tcaswell at gmail.com (Thomas Caswell) Date: Wed, 6 May 2020 11:10:37 -0400 Subject: [Matplotlib-devel] Why keep codecov? In-Reply-To: References: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> Message-ID: My point is that the issue (the coverage on the tests always being reported as going down in unrelated files) is due to a miss-configuration (azure not uploading reports on PRs) rather than a fundamental problem. I think "is the check useful in principle" should be considered separately from "is it currently configured correctly". Tom On Wed, May 6, 2020 at 2:37 AM Eric Firing wrote: > Tom, > > I'm sorry but I don't understand. Let me put it another way: how often > does the codecov flagging and output lead to the discovery and solution > of a real problem? At present, it is clearly an annoyance that incurs a > real penalty by putting false information into the PR listings; if that > isn't balanced by some substantial benefit, then we should drop it. > What am I missing? > > Eric > > On 2020/05/05 5:24 PM, Thomas Caswell wrote: > > I think the current problem with codecov is that on the master branch > > azure uploads coverage reports but it does not an the PR runs which > > leads to the drop in coverage due to the edge cases that are hit > > slightly differently on azure than on travis / appveyor. > > > > Tom > > > > On Tue, May 5, 2020 at 11:21 PM Jody Klymak > > wrote: > > > > Hi Eric, > > > > I agree for the codecov/project check. I don?t see how it helps, > > and I routinely ignore it during reviews because it is pretty > > obscure how you are supposed to fix it. > > > > In my opinion, codecov/patch is pretty helpful to know if someone?s > > new code actually ever gets exercised. > > > > Cheers, Jody > > > > > On May 5, 2020, at 18:55 PM, Eric Firing > > wrote: > > > > > > > > > https://codecov.io/gh/matplotlib/matplotlib/compare/5455bab77e75cee46d260c0f27110d6b4fa78270...3eb471dadd2fd397c840bc98db90a06845697131/changes > > > > > > The link above is what I find for the "failing" codecov test for > > https://github.com/matplotlib/matplotlib/pull/17266, which is > > passing all the other tests. > > > > > > The codecov.io output looks like complete > > garbage, listing a huge number of untouched files. > > > > > > I added 2 tests for the code I modified. As far as I can see, > > from a practical standpoint, codecov is incorrectly flagging the PR > > as failing, leading to a misleading red X in the PR list. > > > > > > I can see how a mechanized code coverage test could be useful for > > a project at an early stage, when it is building up its test > > infrastructure, and at a later stage, to be run occasionally, > > especially when major code additions are made. > > > > > > As it is being run now, however, I think it is impeding, not > > aiding, the development process. > > > > > > I recommend that we remove it from the suite of tests run for > > every PR, or at least keep it out of the accounting for the overall > > "pass/fail" rating of the PR. > > > > > > Eric > > > _______________________________________________ > > > Matplotlib-devel mailing list > > > Matplotlib-devel at python.org > > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel at python.org > > https://mail.python.org/mailman/listinfo/matplotlib-devel > > > > > > > > -- > > Thomas Caswell > > tcaswell at gmail.com > > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Wed May 6 13:02:29 2020 From: efiring at hawaii.edu (Eric Firing) Date: Wed, 6 May 2020 07:02:29 -1000 Subject: [Matplotlib-devel] Why keep codecov? In-Reply-To: References: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> Message-ID: <15d06ce4-af9e-70b9-65ae-ccab1b270dfc@hawaii.edu> On 2020/05/06 5:10 AM, Thomas Caswell wrote: > I think "is the check useful in principle" should be > considered?separately from "is it currently configured correctly". OK, you have identified how it is misconfigured (I guess). Now we can separately consider my question, slightly modified, because what we really care about is reality, not an abstract principle: Is the check useful in practice? Has it in the past, and is it likely in the future, to identify a real problem that we fix, to the benefit of the project? As Jody noted, the codecov/patch seems to be doing something useful, codecov/project does not. Eric From rmay31 at gmail.com Wed May 6 15:21:22 2020 From: rmay31 at gmail.com (Ryan May) Date: Wed, 6 May 2020 13:21:22 -0600 Subject: [Matplotlib-devel] Why keep codecov? In-Reply-To: <15d06ce4-af9e-70b9-65ae-ccab1b270dfc@hawaii.edu> References: <6d72336f-dcaa-f50e-0f59-e47192baea59@hawaii.edu> <15d06ce4-af9e-70b9-65ae-ccab1b270dfc@hawaii.edu> Message-ID: So the benefits of the project coverage: * Catching code paths that no longer run due to dependency changes * Seeing how the PR impacts overall coverage (80% coverage of a large PR is different than 80% of a small one) * Seeing code coverage changes due to other changes in CI configuration So while they're not relevant to 90% of PRs, they're still something that should be checked. I'd argue all of that is great benefit that we can get essentially for free by having the bots do this for us. The problem is that on the matplotlib project there's no trust in the codecov setup, and as a result barely anyone pays attention to them. IMO, that's the problem we need to solve. I agree with Tom that this is a configuration problem for matplotlib. This is not a problem, for example, on MetPy where our codecov setup works perfectly fine. Any occasional inconsistency in results or supposed red herrings usually trace back to problems with our config (codecov's questionable UX aside). Ryan On Wed, May 6, 2020 at 11:02 AM Eric Firing wrote: > On 2020/05/06 5:10 AM, Thomas Caswell wrote: > > I think "is the check useful in principle" should be > > considered separately from "is it currently configured correctly". > > OK, you have identified how it is misconfigured (I guess). Now we can > separately consider my question, slightly modified, because what we > really care about is reality, not an abstract principle: Is the check > useful in practice? Has it in the past, and is it likely in the future, > to identify a real problem that we fix, to the benefit of the project? > > As Jody noted, the codecov/patch seems to be doing something useful, > codecov/project does not. > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: