conda-forge ipykernel-5.1.0-pyh24bf2e0_0 is broken for Windows users about ipykernel-feedstock HOT 19 CLOSED

Should the packages that I had identified in #39 be marked as broken?

Yes, they probably should, but they aren't broken on OSX/Linux. I assume we have to go through Proper Channels to make that happen, as it seems a bit overpowered for the bot to do. Unfortunately burnt most of my discretionary FOSS time on getting these out, so we'll have to Keep Calm and Keep the Issue Open.

Py37 packages are up
https://anaconda.org/conda-forge/ipykernel/files?version=5.1.0

I tested a local env like this:

# environment.yml
name: winsmoke
channels:
- conda-forge
- nodefaults
dependencies:
- jupyterlab
- python=3.7

And everything looks correct on win/linux (don't have a mac):

• starting a kernel in lab
• using nbconvert --execute

from ipykernel-feedstock.

I've been having these issues too. I guess I didn't test it thoroughly enough. I guess we should revert those commits?

from ipykernel-feedstock.

from ipykernel-feedstock.

@rs2 the comment in the file states that the post unlink script used to be included because conda didn't parse json files: https://github.com/conda-forge/ipykernel-feedstock/pull/33/files#diff-9281e96d80111563776ada67648cc668

apparently they upgraded their system and it should have worked.

from ipykernel-feedstock.

{
 "argv": [
  "C:/Users/mark/Miniconda3/envs/temp/bin/python",
  "-m",
  "ipykernel_launcher",
  "-f",
  "{connection_file}"
 ],
 "display_name": "Python 3",
 "language": "python"
}

I guess the slashes are wrong. I think we just need to remove the noarch right, but don't need the postlink script?

from ipykernel-feedstock.

@hmaarrfk You may find that there's no bin/ under C:/Users/mark/Miniconda3/envs/temp.

So, two changes need to be made:

• drop bin/ and
• add .exe:

"C:/Users/mark/Miniconda3/envs/temp/python.exe"

from ipykernel-feedstock.

@hmaarrfk share/jupyter/kernels/python3/kernel.json in https://anaconda.org/conda-forge/ipykernel/5.1.0/download/noarch/ipykernel-5.1.0-pyh24bf2e0_0.tar.bz2 contains "/opt/anaconda1anaconda2anaconda3/bin/python",
whereas https://anaconda.org/anaconda/ipykernel/5.1.0/download/win-64/ipykernel-5.1.0-py36h39e3cac_0.tar.bz2 has "C:\\ci\\ipykernel_1539879631431\\_h_env\\python.exe".

from ipykernel-feedstock.

interesting that there is no bin on windows. I guess I still had the old kernel spec when I was testing in my environment. Do you know how we would add a test to avoid this in the future?

from ipykernel-feedstock.

i guess there was already a test there, it just has to stay arch dependent for a while. :/

from ipykernel-feedstock.

After all, it maybe a conda issue. Search for PrefixReplaceLinkAction in conda/conda#7505.

from ipykernel-feedstock.

In either case, ipykernels is kinda broken and a huge bummer. We should find a workaround.

from ipykernel-feedstock.

mine has been to delete the python kernels folder on my machine. it seems to get regenerated automatically :/

from ipykernel-feedstock.

I think a (strong) rule of thumb should be that any conda recipe that makes use of prefixes should never be declared noarch.

from ipykernel-feedstock.

Good point. Maybe I have to re-add https://github.com/conda-forge/ipykernel-feedstock/pull/33/files#diff-4549cc645c735cb12d844512ce880c2c

from ipykernel-feedstock.

Good catch, folks. Let's go back to arch dependent, but keep the removal of the post-link script.

from ipykernel-feedstock.

from ipykernel-feedstock.

#40 was merged, which gives us re-arched 3.6 packages on all the platforms. Awaiting a PR for #41, I guess leave this open until then?

from ipykernel-feedstock.

Should the packages that I had identified in #39 be marked as broken?

from ipykernel-feedstock.

I think this is resolved!

from ipykernel-feedstock.