Bundling Process (Python Extension) get stuck during Lockfile step

MartinDDDD · January 20, 2025, 7:06am

Hi all,

currently working on expanding my experimental AI extension.

After testing a new node locally tried to bundle and the bundling process gets stuck at the very beginning:

C:\Users\xxx>python "C:\Users\xxx\miniconda3\envs\knime-ext-bundling54\bin\build_python_extension.py" C:\Users\xxx\\src C:\Users\xxx\build1111
INFO:__main__:Filling template files from C:\Users\xxx\miniconda3\envs\knime-ext-bundling54\bin\templates\python-extension-plugin
and storing the resulting plugin to
C:\Users\xxx\AppData\Local\Temp\tmpt3fxndqg\org.finnovationflows.FinnovationFlows-Extension\src\main\python.
Using bundle name 'org.finnovationflows.FinnovationFlows-Extension.channel.bin'.
Using plugin template from 'C:\Users\xxx\miniconda3\envs\knime-ext-bundling54\bin\templates\conda-channel-plugin'.
Rendering plugin to 'C:\Users\xxx\AppData\Local\Temp\tmpt3fxndqg\org.finnovationflows.FinnovationFlows-Extension.channel.bin'...
Using bundle name 'org.finnovationflows.FinnovationFlows-Extension.channel.bin'.
Using fragment template from 'C:\Users\xxx\miniconda3\envs\knime-ext-bundling54\bin\templates\conda-channel-platform-fragment'.
Rendering fragment for linux-64 to 'C:\Users\xxx\AppData\Local\Temp\tmpt3fxndqg\org.finnovationflows.FinnovationFlows-Extension.channel.bin.linux.x86_64'...
Running 'conda-lock lock --micromamba --no-mamba --without-cuda --pypi_to_conda_lookup_file C:\Users\xxx\miniconda3\envs\knime-ext-bundling54\bin\pypi_mapping.yaml -f C:\xxx\src\knime_env.yml -c knime -c conda-forge -c nvidia -c defaults -p linux-64 --lockfile C:\Users\xxx\AppData\Local\Temp\tmpavdwafia\lockfile'...

I updated my knime_env.yml and changed relevant knime packages from 5.3 to 5.4:

  - knime-extension=5.4
  - knime-python-base=5.4

and added a new package:

  - pip:
      - markitdown

I did try a build with 5.4 packages but without markitdown package (other packages listed under - pip I kept) and after 1.5h it was successful.

I then tried again with the package and even after 4 hours no movement and also the temp folder that is created is empty…

Any ideas on how to make that work?
Any way to make the process more “verbose” or to generate additional logs to find out where it is stuck?

MartinDDDD · January 20, 2025, 5:32pm

Was stuck at the same stage all day.

Just CTRL + C’ed it - here’s some more logs although that probably is just driven by the cancellation:

Traceback (most recent call last):
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\build_python_extension.py", line 794, in <module>
    build_extension(
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\build_python_extension.py", line 105, in build_extension
    _build_extension(
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\build_python_extension.py", line 175, in _build_extension
    bundles += _create_conda_channels(render_dir_path, force, config)
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\build_python_extension.py", line 450, in _create_conda_channels
    return bundler.bundle()
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\bundle_channels.py", line 77, in bundle
    self._bundle_fragment(
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\bundle_channels.py", line 119, in _bundle_fragment
    gather_env_specs(
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\gather_env_specs.py", line 205, in gather_env_specs
    _perform_with_conda_lock(
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\gather_env_specs.py", line 48, in _perform_with_conda_lock
    lockfile_dict = _run_conda_lock(env_yaml, platform, channels, lockfile)
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\gather_env_specs.py", line 143, in _run_conda_lock
    run_and_capture(command)
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\bin\utils.py", line 119, in run_and_capture
    output = subprocess.run(command, capture_output=True)
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\lib\subprocess.py", line 507, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\lib\subprocess.py", line 1134, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\lib\subprocess.py", line 1524, in _communicate
    self.stdout_thread.join(self._remaining_time(endtime))
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\lib\threading.py", line 1060, in join
    self._wait_for_tstate_lock()
  File "C:\xxxminiconda3\envs\knime-ext-bundling54\lib\threading.py", line 1080, in _wait_for_tstate_lock
    if lock.acquire(block, timeout):

MartinDDDD · January 29, 2025, 5:03am

up

Any thoughts anyone?

Marc_Lehner · February 17, 2025, 9:42am

Hi @MartinDDDD
We are currently working on replacing conda-lock with pixi-lock which seems to be better at resolving complex dependencies and has no problems on windows with special characters, spaces and long paths. A version of the python-bundling is already publicly available for the nightly build knime-extension-bundling/5.5.0. Maybe that could already solve the problem.

Could you maybe share the environment yml so that we can try to reproduce the environment?

MartinDDDD · February 17, 2025, 9:59am

Hey Marc, thanks a lot for getting back to me!!! Much appreciated :-).

I will try out the nightly for sure!

Question: If it works, does the extension still work for 5.4x or only starting with 5.5?

Here’s the .yml:
knime_env.yml (396 Bytes)

I already tried to excluded markitdown, in which case it works again without issues so seems to be tied to that package…

Marc_Lehner · February 17, 2025, 12:38pm

Hi Martin
Thank you for the knime_env.yml with pixi I created the environment in under a minute, while conda-lock is still stuck after hours. So the nightly bundling should work. However, out of the box, it will not be compatible with 5.4. It might work by manually changing a line in the feature.xml file in the rendered output.

<requires>
      <import feature="org.knime.features.python3.nodes" version="5.5" match="greaterOrEqual"/>
    </requires>

the version needs to be changed to 5.4. Then it should be compatible with 5.4.2

MartinDDDD · February 17, 2025, 1:12pm

That is very good news - thank you so much for the feedback

I take that all the steps - e.g. setting up env, setting up bundling env. work the same as in 5.4 with the exception that I pass in 5.5 where 5.4 is referenced in the current docs?

Marc_Lehner · February 18, 2025, 9:08am

The following steps worked for a demo extension:

Create a conda environment with the nightly extension-bundling: conda create -n knime_nightly_bundling -c knime/label/nightly -c conda-forge knime-extension-bundling=5.5
Activate it conda activate knime_nightly_bundling
Build the python extension like normal but with the argument for the render directory: build_python_extension pathToMyExtension outputWeDontNeed --render-folder render_dir
cd render_dir
Now we need to change all occurrences of 5.5 to 5.4 for the extension and dependencies. The easiest is a sed command or a replace all in an IDE like VSCode
Then we need to repackage the extension mvn clean package
And finally we can move the folder render_dir/org.knime.python.update.NameOfExtension/target/repository/* to the intended destination of the extension from where it can be installed in KNIME by adding the destination folder as an update site like normal.

This is a hacky workaround, but it should work in many cases if you need the extension to run in 5.4 until 5.5 is released.

Vincent_Luyten · February 20, 2025, 1:58pm

Got the same issue and with these steps was able to get past the pixi part but now fails on maven:
INFO:main:Running maven build ‘mvn package’…
Downloading from central: https://repo.maven.apache.org/maven2/org/eclipse/tycho/tycho-build/3.0.3/tycho-build-3.0.3.pom
[ERROR] Error executing Maven.
[ERROR] Extension org.eclipse.tycho:tycho-build:3.0.3 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.eclipse.tycho:tycho-build:jar:3.0.3
[ERROR] Caused by: Failed to read artifact descriptor for org.eclipse.tycho:tycho-build:jar:3.0.3
[ERROR] Caused by: Failed to read artifact descriptor for org.eclipse.tycho:tycho-build:jar:3.0.3
[ERROR] Caused by: Could not transfer artifact org.eclipse.tycho:tycho-build:pom:3.0.3 from/to central (Central Repository:): PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[ERROR] Caused by: Could not transfer artifact org.eclipse.tycho:tycho-build:pom:3.0.3 from/to central (Central Repository:): PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[ERROR] Caused by: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[ERROR] Caused by: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[ERROR] Caused by: unable to find valid certification path to requested target
Traceback (most recent call last):
File “/Users/vincentluyten/miniconda3/envs/knime_nightly_bundling/bin/build_python_extension.py”, line 799, in
build_extension(
File “/Users/vincentluyten/miniconda3/envs/knime_nightly_bundling/bin/build_python_extension.py”, line 125, in build_extension
_build_extension(
File “/Users/vincentluyten/miniconda3/envs/knime_nightly_bundling/bin/build_python_extension.py”, line 194, in _build_extension
_run_maven_build(
File “/Users/vincentluyten/miniconda3/envs/knime_nightly_bundling/bin/build_python_extension.py”, line 505, in _run_maven_build
raise RuntimeError(“Maven build failed.”)
RuntimeError: Maven build failed.

steffen_KNIME · February 21, 2025, 8:55am

Hi @Vincent_Luyten!

there are three different approaches regarding PKIX issues in the following thread, please have a look there and tell us what did (not) work to solve your issue

Best
Steffen

MartinDDDD · February 22, 2025, 6:23pm

Thanks Marc for the detailed instructions.

It worked like a charm until I tried to install from local update side:

Create_env.err shows:

C:\K\KAP54\bundling\envs\org_finnovationflows_FinnovationFlows-Extension_0.3.0\python.exe: No module named pip

Given that this is a hacky workaround I then tried again after changing my env.yml to include pip before pip: - pckg1:

- ...
- pip
- pip: 
   - markitdown
   - ...

Unfortunately no joy and same error…

Feels like it is close although pip missing is an odd one

forum · April 13, 2025, 9:32am

Internal ticket ID: AP-24020
Summary: Pip missing when installing extensions bundled in 5.5
Fix version(s): 5.5.0

MartinDDDD · April 21, 2025, 5:21pm

To close the loop on this:

Marc’s steps referenced above (I will mark as solution) worked with the latest nightly built. I had to clean my cache in

C:\Users\myUser\.m2\repository\

and after it everything worked like a charm.

Can’t wait for 5.5 though :-).

system · April 28, 2025, 5:21pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.