Test downstreams (ipykernel)

bollwyvl commented 5 years ago

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Investigating issues observed over on https://github.com/conda-forge/ipykernel-feedstock/pull/43

conda-forge-linter commented 5 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

minrk commented 5 years ago

downstream tests are cool! Can we do this on ipython/ipython instead, where we will get this feedback at a more useful time? There's not a lot we can do here based on failures (which are usually invalid assumptions in tests, as in conda-forge/ipykernel-feedstock#43, and not bugs anywhere in the code).

bollwyvl commented 5 years ago

Can we do this on ipython/ipython instead, where we will get this feedback at a more useful time?

Well, this can still be useful, as we get stuff like bad path detection, etc. But agreed, it's a bit late at this point :P Are you imagining having a conda-build step in i/i, or just running the tests in a separate travis/appveyor/osx excursion?

minrk commented 5 years ago

I agree it's still useful. I mainly mean that it would be more useful to do the same thing, just on the repo where action can be taken, rather than here, where issues can be found only after releases are made, and fixed (or tested) only after another release is made. My frustration here is that test failures occurring on these repos have almost always been issues that should be fixed in the test suite of the upstream package, and irrelevant to whether a version should be packaged on conda-forge, which is my interpretation of the red X on this repo. While that X is useful information for me as a maintainer of IPython, it's not useful information on this repo, and especially not useful to anyone who might be a maintainer on conda-forge but not IPython.

Rather than conda-build, I'd install and run the tests for ipykernel in an allow_failure matrix entry on travis. Should be much simpler, approximately (I hope):

pip install 'ipykernel[test]'
pytest --pyargs ipykernel

Alternately, we could revive the test grid project to verify that masters and latest stables are compatible.

bollwyvl commented 4 years ago

Given the challenges on #100, #103, let's not add any further cyclical dependencies...

conda-forge / ipython-feedstock

Test downstreams (ipykernel) #67