flatpak-node-generator
flatpak-builder version
1.4.0
Linux distribution and version
arch linux
Affected flatpak-builder tool
node/flatpak-node-generator.py
flatpak-builder tool cli args
No response
Source repository URL
https://github.com/h3poteto/whalebird-desktop
Flatpak-builder manifest URL
No response
Description
when attempted to generate the sources with the latest version of flatpak-node-generator the whole thing blows up with the following output
Found 1 lockfiles.
Reading packages from lockfiles...
Traceback (most recent call last):
File "/home/luna/.local/bin/flatpak-node-generator", line 8, in <module>
sys.exit(main())
^^^^^^
File "/home/luna/.local/share/pipx/venvs/flatpak-node-generator/lib/python3.11/site-packages/flatpak_node_generator/main.py", line 277, in main
asyncio.run(_async_main())
File "/usr/lib/python3.11/asyncio/runners.py", line 190, in run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/asyncio/runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/home/luna/.local/share/pipx/venvs/flatpak-node-generator/lib/python3.11/site-packages/flatpak_node_generator/main.py", line 198, in _async_main
packages.update(lockfile_provider.process_lockfile(lockfile))
File "/home/luna/.local/share/pipx/venvs/flatpak-node-generator/lib/python3.11/site-packages/flatpak_node_generator/providers/yarn.py", line 106, in process_lockfile
for name_line, package in self.parse_lockfile(lockfile).items():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/luna/.local/share/pipx/venvs/flatpak-node-generator/lib/python3.11/site-packages/flatpak_node_generator/providers/yarn.py", line 68, in parse_lockfile
key, value = shlex.split(line)
^^^^^^^^^^
ValueError: too many values to unpack (expected 2)
I'm not to sure why this is happening any pointers would be helpful
I added some print statements to see on which line it errors. This was the output for the specific program the op mentioned:
"@babel/core": ^7.4.0 || ^8.0.0-0 <8.0.0
"@babel/core": ^7.0.0-0 || ^8.0.0-0 <8.0.0
react: ^16.8 || ^17 || ^18
eslint: ^6.0.0 || ^7.0.0 || >=8.0.0
typescript: ^4.7 || 5
react: ^16 || ^17 || ^18
react-dom: ^16 || ^17 || ^18
conditions: os=darwin & cpu=arm64
conditions: os=darwin & cpu=x64
conditions: os=linux & cpu=arm64 & libc=glibc
conditions: os=linux & cpu=arm64 & libc=musl
conditions: os=linux & cpu=x64 & libc=glibc
conditions: os=linux & cpu=x64 & libc=musl
conditions: os=win32 & cpu=arm64
conditions: os=win32 & cpu=ia32
conditions: os=win32 & cpu=x64
acorn: ^6.0.0 || ^7.0.0 || ^8.0.0
"@babel/core": ^7.4.0 || ^8.0.0-0 <8.0.0
"@babel/core": ^7.4.0 || ^8.0.0-0 <8.0.0
"@babel/core": ^7.4.0 || ^8.0.0-0 <8.0.0
jsx-ast-utils: ^2.4.1 || ^3.0.0
eslint: ^3 || ^4 || ^5 || ^6 || ^7 || ^8
minipass: ^5.0.0 || ^6.0.2 || ^7.0.0
js-tokens: ^3.0.0 || ^4.0.0
lru-cache: ^9.1.1 || ^10.0.0
minipass: ^5.0.0 || ^6.0.2 || ^7.0.0
"@types/react": 16 || 17 || 18
react: ^16.6.0 || 17 || 18
typescript: ^4.7 || 5
The problem as we can see is that it splits it on spaces, therefore we do not have 2 return values of shlex.split(line) but for example on "@babel/core": ^7.4.0 || ^8.0.0-0 <8.0.0 we would get: ['@babel/core:', '^7.4.0', '||', '^8.0.0-0', '<8.0.0'].
The issue no longer occurs when applying the #252 pull request to my install.