At the moment, the recipe for ipykernel includes an explicit call to ipykernel install

    - {{ PYTHON }} -m ipykernel install --prefix {{ PREFIX }}

which in turns calls the jupyter-kernel entry point from jupyter_client. We have seen this cause some issues with permissions on windows, namely [Errno 13] Permission denied: 'C:\\xeus-conda\\Scripts\\jupyter-kernel.exe'.

In fact, we should not need to do this at all since a kernel spec can be included as part of the python package. The only issue with the current way the default kernelspec file generated by setup.py is made with make_ipkernel_cmd(executable='python') so that the kernel spec argv simply specifies "python" instead of the full sys.executable.

One way to fix this, would be for setup.py to check if some environment variable is set (e.g. IPYKERNEL_PYTHON) pass it to the executable kwargs.

Then the install command would merely be:

{{ PYTHON }} -m pip install . --no-deps --ignore-installed

Comment:

So with the recently noarch_platform in the newer smithies, it's possible we could actually solve the one-windows-path-json problem by making two noarch packages with the same name with two different variants:

• slashes: with run: __unix
• backslashes: with run_constrained: __unix <0 package

This would potentially leave us with just two builds, and no platform/migration issues.

Example:

• https://github.com/conda-forge/pywin32-on-windows-feedstock/blob/main/recipe/conda_build_config.yaml
• https://github.com/conda-forge/pywin32-on-windows-feedstock/blob/main/recipe/meta.yaml

#40 got merged, but we need to wait for the bot to PR the migration to py37.

It seems that there are broken packages due to missing dependencies out in the wild:

Steps to reproduce:

mamba create -n foo27  python=2.7 ipykernel
python -m ipykernel install

gives following error:

[...]
  File "/Users/christian/miniconda3/envs/foo27/lib/python2.7/site-packages/wcwidth/__init__.py", line 12, in <module>
    from .wcwidth import ZERO_WIDTH  # noqa
  File "/Users/christian/miniconda3/envs/foo27/lib/python2.7/site-packages/wcwidth/wcwidth.py", line 79, in <module>
    from backports.functools_lru_cache import lru_cache
ImportError: No module named functools_lru_cache

conda list ipykernel --show-channel-urls

ipykernel                 4.10.0                   py27_0    conda-forge

I know the time of python 2.7 is over, but I suggest we remove those broken builds to reduce friction for our users.

Issue:
aarch64 support through noarch is stuck at 5.1.0 : see here

background:
I am trying to get a spyder-kernels running on aarch64.
The building of spyder-kernels fails on aarch64 with the following error:

conda_build.exceptions.DependencyNeedsBuildingError: Unsatisfiable dependencies for platform linux-aarch64: {"ipykernel[version='>=5.1.3']"}

so spyder-kernels needs ipykernel >=5.1.3 ... and yes, that is not available for aarch64 ... doing conda search ipykernel on my aarch64 box yields:

(base) tho@ubuntu:~$ conda search ipykernel
Loading channels: done
# Name                       Version           Build  Channel             
ipykernel                      5.0.0            py_0  conda-forge         
ipykernel                      5.0.0    pyh24bf2e0_1  conda-forge         
ipykernel                      5.1.0    pyh24bf2e0_0  conda-forge         

exactly the same is in the link in the issue above 😞

suggestion:
organize explicit aarch64 support by changing the provider in conda-forge.yml
from :

• provider: {linux_aarch64: native, linux_ppc64le: default, win: azure}

to:

• provider: {linux_aarch64: default, linux_ppc64le: default, win: azure}

... not sure if bumping the build number is needed if we go this way 🤔

# packages in environment at /home/tho/miniforge3:
#
# Name                    Version                   Build  Channel
binutils_impl_linux-aarch64 2.29.1               hc862510_0    c4aarch64
ca-certificates           2019.11.28           hecc5488_0    conda-forge
certifi                   2019.11.28               py37_0    conda-forge
cffi                      1.13.2           py37h8022711_0    conda-forge
chardet                   3.0.4                 py37_1003    conda-forge
conda                     4.8.2                    py37_0    conda-forge
conda-package-handling    1.6.0            py37h516909a_1    conda-forge
cryptography              2.8              py37h72c5cf5_1    conda-forge
idna                      2.8                   py37_1000    conda-forge
libffi                    3.2.1             h4c5d2ac_1006    conda-forge
libgcc-ng                 7.3.0                h5c90dd9_0    c4aarch64
libstdcxx-ng              7.3.0                h5c90dd9_0    c4aarch64
ncurses                   6.1               hf484d3e_1002    conda-forge
openssl                   1.1.1d               h516909a_0    conda-forge
pip                       20.0.2                   py37_0    conda-forge
pycosat                   0.6.3           py37h516909a_1002    conda-forge
pycparser                 2.19                     py37_1    conda-forge
pyopenssl                 19.1.0                   py37_0    conda-forge
pysocks                   1.7.1                    py37_0    conda-forge
python                    3.7.6                heaf0f07_2    conda-forge
readline                  8.0                  h75b48e3_0    conda-forge
requests                  2.22.0                   py37_1    conda-forge
ruamel_yaml               0.15.80         py37h516909a_1000    conda-forge
setuptools                45.1.0                   py37_0    conda-forge
six                       1.14.0                   py37_0    conda-forge
sqlite                    3.30.1               h283c62a_0    conda-forge
tk                        8.6.10               hed695b0_0    conda-forge
tqdm                      4.42.0                     py_0    conda-forge
urllib3                   1.25.7                   py37_0    conda-forge
wheel                     0.33.6                   py37_0    conda-forge
xz                        5.2.4             hda93590_1001    conda-forge
yaml                      0.2.2                h516909a_1    conda-forge
zlib                      1.2.11            h516909a_1006    conda-forge

     active environment : base
    active env location : /home/tho/miniforge3
            shell level : 1
       user config file : /home/tho/.condarc
 populated config files : /home/tho/miniforge3/.condarc
          conda version : 4.8.2
    conda-build version : not installed
         python version : 3.7.6.final.0
       virtual packages : __glibc=2.30
       base environment : /home/tho/miniforge3  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/linux-aarch64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/c4aarch64/linux-aarch64
                          https://conda.anaconda.org/c4aarch64/noarch
          package cache : /home/tho/miniforge3/pkgs
                          /home/tho/.conda/pkgs
       envs directories : /home/tho/miniforge3/envs
                          /home/tho/.conda/envs
               platform : linux-aarch64
             user-agent : conda/4.8.2 requests/2.22.0 CPython/3.7.6 Linux/5.3.0-1014-raspi2 ubuntu/19.10 glibc/2.30
                UID:GID : 1001:1001
             netrc file : None
           offline mode : False

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Looking at https://anaconda.org/conda-forge/ipykernel/files, I see that only two variants of the 6.24 package were built: __win and __linux, but no __osx package was built. Notice that 6.23.3 has three variants built. 6.24 was built 3 days ago - perhaps this is a delay in building osx packages?

The effect is that I cannot install ipykernel 6.24 on a mac m1 with micromamba using conda-forge

$ micromamba create -n ipykernel ipykernel=6.24
conda-forge/osx-arm64                                       Using cache
conda-forge/noarch                                          Using cache
error    libmamba Could not solve for environment specs
    The following packages are incompatible
    └─ ipykernel 6.24**  is not installable because there are no viable options
       ├─ ipykernel 6.24.0 would require
       │  └─ __win, which is missing on the system;
       └─ ipykernel 6.24.0 would require
          └─ __linux, which is missing on the system.
critical libmamba Could not solve for environment specs

Installed packages

Clean environment

Environment info

$ micromamba info

       libmamba version : 1.4.7
     micromamba version : 1.4.7
           curl version : libcurl/7.88.1 SecureTransport (OpenSSL/3.1.1) zlib/1.2.13 zstd/1.5.2 libssh2/1.11.0 nghttp2/1.52.0
     libarchive version : libarchive 3.6.2 zlib/1.2.13 bz2lib/1.0.8 libzstd/1.5.2
[snip]
       virtual packages : __unix=0=0
                          __osx=13.4.1=0
                          __archspec=1=arm64
               channels : https://conda.anaconda.org/conda-forge/osx-arm64
                          https://conda.anaconda.org/conda-forge/noarch
[snip]
               platform : osx-arm64

I'm trying to test Windows for a setup using explicit links. Since I don't have access to a Windows machine at the moment, I set up an environment with a .yml that passed my tests and I printed the explicit list, then using that for the same tests. The setup is available to look here:

https://github.com/darribas/gds_env/blob/master/appveyor.yml

Appveyor fails apparently on conda-forge::ipykernel:

https://ci.appveyor.com/project/darribas/gds-env/build/job/xcs438v02hd1jid6

Any idea what that link error means? Any suggestion/help would be most appreciated. Thank you very much!

Additional comment:

No response

Users reported problems with a fresh conda environment while running:

> jupyter notebook --ip=127.0.0.1

The kernel died immediately with some Windows error message: [Error2] System cannot find file (translated from german).

This can be fixed by getting the kernelspec file via:

> jupyter kernelspec list

and deleting the kernel.json at the displayed path.

I quickly checked the conda-forge ipykernel archives and the default one. The only difference: In the conda-forge there is another folder share which has the kernelspec json-file inside.

But the path within the json file is wrong also after installation:

{
 "display_name": "Python 2", 
 "language": "python", 
 "argv": [
  "C:\\conda\\envs\\_build\\python.exe", 
  "-m", 
  "ipykernel", 
  "-f", 
  "{connection_file}"
 ]
}

I'm not sure, how this should work, but this path should be changed to the correct location while installing ipykernel-package.

Additional comment:

No response

Since #55, every time the feedstock is rerendered, to get correct behavior on windows path rewriting in the kernelspec.json, we must patch the windows azure job to pin to an older version of conda-build.
This no doubt ripples out into other kernel feedstocks, e.g. conda-forge/sos-notebook-feedstock#42

It would be good to figure out how to not have to do this.

Some (not mutually exclusive) options:

• go back to using POSIX paths in JSON
  • windows can use POSIX slashes just fine, and they don't conflict with JSON escaping
  • will they get rewritten by conda-build now? in the future?
  • already tried this, but may be worth trying again
• post-link.(bat|sh)
  • really don't want to do this
• do nothing (keep patching, hope for it to work itself out)
• conda-build upstream
  • raise an issue
  • make a PR
  • wait for a release (this can be slow)
• conda-smithy usptream
  • raise an issue for a conda-build flag per provider, in conda-forge.yml
  • make a PR
  • wait for a release (this is usually pretty quick)
  • doesn't really solve the issue

@conda-forge admin please rerender

For now, it looks like we won't be able to have 6.x builds against pypy on unix due to some fairly basic lifecycle issues (kernels can't be stopped). So that we can start getting some of the good features, I've proposed skipping pypy/unix for 6.0.0_*_0 on #84.

Simultaneously, we're trying to land the novel windows pypy37 variant on #83 (still apparently blocked by some upstreams), and just don't have enough data to know whether it's going to work. I propose we:

• create a 5.x branch from the current master
• add it to the abi flag, a la ipython
• get the bot to retarget the PR against 5.x

Related:

• #83
• #84
  • ipython/ipykernel#700
    • erdewit/nest_asyncio#55
      • jupyter/jupyter_client#663

@conda-forge-admin, please update circle

• I read the conda-forge documentation and could not find the solution for my problem there.

Issue: I am currently having python3.7 installed, and I would like to install the latest ipykernel. Strangely, I see that it requires importlib-metadata <4. I wonder, if this limit can be removed?
ipykernel>6 is needed for us to use jupyterlab debugger extension!

Running code under coverage on pypy is very slow, and is likely contributing to some of our flake here. On a future release, let's disable pypy coverage.

We just closed a couple PRs targeting 5.x... are we done with that branch at this point? If i recall correctly, we added it to get pypy support, but as of #106, it looks like we have pypy37 on the major platforms for 6.x

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=419834&view=results

Symptoms

KernelError in Jupyter Notebooks running on win-64 architecture.

Problem

ipykernel-5.1.0 is being classified as noarch in conda-forge. As such, the tarball is missing .ipykernel-post-link.bat that is important for win-64 platforms: it fixes the path in kernels/python3/kernel.json.

NB: ipykernel-5.1.0 is correctly classified as architecture-dependent in the defaults anaconda channel.

Compare:

• win-64-compatible ipykernel-5.1.0 in defaults channel.
• noarch ipykernel-5.1.0 in conda-forge.

@blink1073, @hmaarrfk What was the rationale behind marking ipykernel as noarch in 227b6cc (#34)?

Hi @conda-forge/ipykernel! This is the friendly automated conda-forge-webservice!

It appears that one or more of your feedstock's outputs did not copy from the
staging channel (cf-staging) to the production channel (conda-forge). :(

This failure can happen for a lot of reasons, including an outdated feedstock
token. Below we have put some information about the failure to help you debug it.

Rerendering the feedstock will usually fix these problems.

If you have any issues or questions, you can find us on gitter in the
community chat room or you can bump us right here.

error messages:

• invalid feedstock token

Hi,

the osx osx_64_numpy1.21python3.10.____cpython run for the last upload failed. Could that be restarted please, thanks!

Ref: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=460147&view=logs&j=385a3385-ae8b-54d1-9abe-3c614f74cb73

Additional comment:

No response

#75 and #76 are both looking good except for ppc. I don't think we want to hold up the ship for that platform (seldom get more than 100 downloads per version). If someone really cares, PRs welcome, but otherwise we'll probably just want to try rekicking it next week or something.

Hello everyone,

I have a question: I'm currently doing the Udacity Self Driving Car Engineer nanodegree program.

To solve the tasks, an environment is built up, based on an yml file with the content:

name: carnd-term1
channels:
- https://conda.anaconda.org/menpo
- conda-forge
dependencies:
- python==3.5.2
- numpy
- matplotlib
- jupyter
- opencv3
- pillow
- scikit-learn
- scikit-image
- scipy
- h5py
- eventlet
- flask-socketio
- seaborn
- pandas
- ffmpeg
- imageio=2.1.2
- pyqt=4.11.4
- pip:
- moviepy
- tensorflow==0.12.1
- keras==1.2.1

When I activate via "conda env create -f environment.yml", I get back the following error:

ERROR conda.core.link:_execute_actions(318): An error occurred while installing package 'conda-forge::ipykernel-4.8.2-py35_0'.
LinkError: Link error: Error: post-link failed for: conda-forge::ipykernel-4.8.2-py35_0

This happens on Windows 10. The very same file works on Mac OS X. Any ideas, anyone, how to solve this?

Thanks, Patrick

The Windows 32-bit and 64-bit ipykernel-4.6.1-py35_0.tar.bz2 Conda package available from the conda-forge channel include the following file (though they shouldn't):

Lib/site-packages/__pycache__/six.cpython-35.pyc

Note that the above file is (correctly) not included in the Python 3.6 release, i.e., ipykernel-4.6.1-py36_0.tar.bz2.

Implications

This file is included in the six package and causes, for example, the following duplicate file errors when building a Miniconda installer using constructor:

Error: File 'Lib/site-packages/__pycache__/six.cpython-35.pyc' found in multiple packages: ipykernel-4.6.1-py35_0.tar.bz2, six-1.10.0-py35_1.tar.bz2