our IT tested long name hint you gave with the other post but it didn’t help.
They further investigated the installation process and found out that there is the programm/commando “micromamba”, which is trying to install something, is ignorign the Proxy-settings and wants direct access, which is not possible.
These nodes are not KNIME nodes but third party nodes right? Whom to ask?
I think I asked Micha already for a solution in a similiar issue with the new geospatial nodes, which also are not real KNIME nodes but Python nodes and also do not respect the needed proxy.
That seems to be a pure proxy issue then. We implemented some proxy tricks in 5.2, but I do not know the details. Let’s ask @carstenhaubold ! Carsten, do you happen to know whether the above issue might be fixed in 5.2?
I just checked out the old ticket (https://knime.zendesk.com/hc/en-gb/requests/31726) and found we were discussing the OSM nodes, which we where able to install, but then they were not able to fetch the map data while trying to use them due to not using our proxy settings. Sorry for the confusion with the geospatial nodes.
PS. I just tested the installation of the geospatial nodes too and they give me the same error:
An error occurred while installing the items
session context was:(profile=KNIMEProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null → [R]sdl.harvard.geospatial.channel.bin.win32.x86_64 1.2.0.202309272119, action=org.knime.product.p2.actions.ShellExec).
ShellExec command exited non-zero exit value:
Sorry to hear that you’re having trouble installing Python-based extensions. It does indeed look like the Python packages required by our extensions cannot be downloaded from conda-forge, which happens during plugin installation.
Is it possible for you to configure a proxy so that the Python packages can be downloaded?
Hi @carstenhaubold , I have spent several hours yesterday with our IT trying to find out whats going on and failed. As I have learned our IT is shipping Anaconda and inside of the folder is the .condarc file. That works perfectly fine since years. However, I have tried to place the file in the user folder too and there was no change - the installation failed. We were further investigating the issue and wanted to find out where the KNIME conda folder is to place the files there. Finally, we discovered the folder …\knime_5.1.0\plugins\org.knime.python.web.channel.bin.win32.x86_64_5.1.0.202308031143, but placing the file there did not help either. I tried to run the micromamba.bat I found there and found that alle files needed seem to be downloaded successfully, but there is an error: critical libmamba ssl_verify does not contain a valid file path.
How do I fix that?
Thanks a lot!
Lars
PS. I just found in the Internet the comment "Micromamba struggles with ssl when working with an atypical network setup.
Unlike Miniconda, Micromamba does not have an option to disable ssl verification. "
Is there an option that we solve that together in a webmeeting?
As you say you have Anaconda installed and working, and I am finding more and more cases where conda works while mamba/micromamba fails, I am thinking that we need to add the option to let our users provide a conda executable used when creating the environments for Python-based KNIME extensions. We’ll look into that and get back to you to test a prototype, ok?
thanks a lot! Would be great to have a fallback solution if micromamba is not working as expected. Yes, Anaconda and Miniconda are working fine for us. I am not aware of the tool ZScaler. I would be happy to test.
