`pack update`: Error: relative url without a base

[rapgenic]

When I try to run pyocd pack update, I get the following error:

0000262 I Updating pack index... [pack_cmd]
RelativeUrlWithoutBases (804/838)
0002770 C Error: b'\nrelative URL without a base' [__main__]
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/pyocd/__main__.py", line 161, in run
    status = cmd.invoke()
  File "/usr/local/lib/python3.10/dist-packages/pyocd/subcommands/pack_cmd.py", line 112, in invoke
    cache.cache_descriptors()
  File "/usr/local/lib/python3.10/dist-packages/cmsis_pack_manager/__init__.py", line 299, in cache_descriptors
    pdsc_index = self._call_rust_update(progress_fn)
  File "/usr/local/lib/python3.10/dist-packages/cmsis_pack_manager/__init__.py", line 244, in _call_rust_update
    return self._poll_rust_update(poll_obj, on_tick_fn)
  File "/usr/local/lib/python3.10/dist-packages/cmsis_pack_manager/__init__.py", line 247, in _poll_rust_update
    with _RaiseRust():
  File "/usr/local/lib/python3.10/dist-packages/cmsis_pack_manager/__init__.py", line 36, in __exit__
    raise Exception(ffi.string(maybe_err))
Exception: b'\nrelative URL without a base'

I suspect this might be actually a cmsis_pack_manager issue however, given the stacktrace

[rapgenic]

I don't know what caused it, but now it seems it's working again...

[knthm]

I was having this issue today.

Manually installing the latest pyocd==0.34.3 and cmsis_pack_manager==0.5.2 versions helped, since the newer version will skip failing PDSC downloads without aborting the whole pyocd pack update operation.

IMHO the whole PDSC retrieval mechanism is flawed, they should be centrally cached somewhere reliable, rather than require users to directly download them from the manufacturer's (often unreliable) sites—but that's a conversation for the cmsis-pack-manager repo.

[flit]

There are a number of things that could be improved with PDSC and pack management, for sure… 🥲 That's really a discussion for the Open-CMSIS-Pack working group. cmsis-pack-manager (and pyocd by way of it) just implement the specification. cmsis-pack-manager could certainly extend the implementation, but I'd personally rather it be solved upstream so everyone benefits.

Fwiw, I haven't seen this issue before. It could perhaps be caused by a vendor adding an incorrect path to their index, then fixing it?

Regardless, the actual error should be caught and ignored. That will have to be done in cmsis-pack-manager, so the index update can finish retrieving valid PDSCs. Created pyocd/cmsis-pack-manager#210.

[knthm]

That's really a discussion for the Open-CMSIS-Pack working group

Understood, thank you for the guidance. I only have cursory knowledge of Open-CMSIS-Pack stemming from this rabbit hole I fell into today, when all I really wanted to do was flash a Zephyr build via pyOCD to a STM32WL uC :smile:

It could perhaps be caused by a vendor adding an incorrect path to their index

I suppose that's possible, I was initially using pyOCD 0.29.0 and cmsis-pack-manager 0.3.0 as those are the versions pulled by the respective requirements-run-test.txt from Zephyr.

Before the error mentioned in this issue, I actually ran into a different error for another pack, where a manufacturer's site couldn't be resolved by my DNS provider (mongoose.ws via Quad9). This had also stopped the pack update operation.

After working around the DNS issue, I ran into the issue in this thread, hence my disillusionment with the manufacturers' hosting capabilities :wink: Even now I still get a large list of timeout issues in retrieving many packs, though it's not a big issue as these are skipped after the timeout duration.

cmsis-pack-manager has come a long way in dealing with the pack retrieval issues since 0.3.0 though, for which I'm very thankful.

I'll try to get a PR merged in Zephyr that bumps the required pyOCD (and thus cmsis-pack-manager) version, so fewer people see these issues in the wild.