Arch linux error

[Slapspat]

note: This error originates from a subprocess, and is likely not a problem with pip. ERROR: Failed building wheel for numpy Failed to build numpy ERROR: Could not build wheels for numpy, which is required to install pyproject.toml-based projects

This is what I get trying to install it. I have numpy and pyproject.toml-based installed. Just not wanting to work.

[HGStone]

use python 3.8

[Slapspat]

I have python 3.10 currently installed and did try to install 3.9 instead. My arch linux came with python 3.10 by default.

[NiceneNerd]

Python 3.10 is not supported on any OS. I suggest using pyenv.

[v-fox]

Python 3.10 is not supported on any OS. I suggest using pyenv.

But why do you force numpy-1.19.5 that doesn't compile with python-3.10 instead of numpy-1.21.6 that does ?

I replaced all '~=' directives with '>=' in bcml, aamp, botw_havok, byml-v2 and replaced outdated bugged zlib-ng in syaz0 (even though it has no business building its own copy of a core system lib), allowing me to run python3 ./setup.py build && CFLAGS="-fPIC -O3 -march=x86-64 -mtune=generic -pthread -w" CXXFLAGS="$CFLAGS" LDFLAGS="-fPIC -Wl,-O1" python3 ./setup.py install --user on them, installing into ~/.local/lib/python3.10/site-packages (which I'm going to nuke anyway because I don't need any development crap in /home but it's just a test for 1-time use or trying to make a system package later). But this failed with:

Traceback (most recent call last):
  File "${HOME}/.local/bin/bcml", line 33, in <module>
    sys.exit(load_entry_point('bcml==3.9.26', 'gui_scripts', 'bcml')())
  File "${HOME}/.local/bin/bcml", line 25, in importlib_load_entry_point
    return next(matches).load()
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 171, in load
    module = import_module(match.group('module'))
  File "/usr/lib64/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "${HOME}/.local/lib/python3.10/site-packages/bcml-3.9.26-py3.10.egg/bcml/__main__.py", line 16, in <module>
    from bcml import DEBUG, util, _oneclick
  File "${HOME}/.local/lib/python3.10/site-packages/bcml-3.9.26-py3.10.egg/bcml/util.py", line 40, in <module>
    from bcml import bcml as rsext
ImportError: cannot import name 'bcml' from 'bcml' (~/.local/lib/python3.10/site-packages/bcml-3.9.26-py3.10.egg/bcml/__init__.py)

Running from source-directory without installing ends up with similar:

fox@arsenal (16:32:19) [ /media/storage-t1T/games_consoles/Nintendo Wii U/The Legend of Zelda Breath of the Wild (Mods)/BCML/SOURCE ] % python3 -m bcml            
Traceback (most recent call last):
  File "/usr/lib64/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib64/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/media/storage-t1T/games_consoles/Nintendo Wii U/The Legend of Zelda Breath of the Wild (Mods)/BCML/SOURCE/bcml/__main__.py", line 16, in <module>
    from bcml import DEBUG, util, _oneclick
  File "/media/storage-t1T/games_consoles/Nintendo Wii U/The Legend of Zelda Breath of the Wild (Mods)/BCML/SOURCE/bcml/util.py", line 40, in <module>
    from bcml import bcml as rsext
ImportError: cannot import name 'bcml' from 'bcml' (/media/storage-t1T/games_consoles/Nintendo Wii U/The Legend of Zelda Breath of the Wild (Mods)/BCML/SOURCE/bcml/__init__.py)

Neither does work going with craptacular maturin/cargo/rust route (creating whole sandbox with gigabyte of bastardized LLVM/clang fork for some measly python app is crazy from system maintenance point of view anyway): maturin develop fails because it wants some unexplained virtualenv/conda sandbox which I have no interest of having and maturin build fails because bcml has hardcoded dependency (as rust does in its horrendous Cargo.toml files invented by lovecraftian madmen) on rstb-0.3.2 which has hardcoded directive #![feature(exclusive_range_pattern)] which obsoleted "release" version of rust (which itself relies on obsoleted LLVM-14) refuses to comply or skip while also refusing to use "develop" version because the lovecraftian madmen said so.

This is kind of dependency hell you will never see on Linux. Unless you deal with the lovecraftian madmen that manage to fork a simple compiler and build such fortified swamp around it.

[NiceneNerd]

A'ight then

But IDK what you mean about "dependency hell you will never see on Linux" when BCML was developed primarily on Linux.

[v-fox]

A'ight then

Actually, setting up venv that makes maturin develop run doesn't work either because it also uses latest available rust (1.64) in the distro which rstb-0.3.2 doesn't like just the same. And pre-compiled Linux binary from pip is broken. Running Windows version from pip in wine also doesn't work because it wants working MSVC compiler environment which is non-trivial to set up. So, there is no way to compile or run it until you fix up compilation dependencies or recompile pip package with safe generic flags.

But IDK what you mean about "dependency hell you will never see on Linux" when BCML was developed primarily on Linux.

I don't know what kind of Linux you've been using but in 20 years of my experience you either put 1 command to system packet manager to get a package from automated build-server or install dependencies also with 1 command and then run a build-script which will make an app that uses all current system dependencies and get installed in proper, standardized, easily maintainable shared places. There is a reason why standard distro policy is "compile everything against latest versions of everything, older dependencies in repositories only for badly maintained irreplaceable apps that a distro maintainer can't easily fix to port unto current dependencies without developers unscrewing their unportable code themselves". Meaning that any "< $version" directive is compromise, not a normal thing to do.

What you will NOT do is setting up entire hundreds or thousands of megabytes of toolchain for an outdated compiler fork (rust is just bastardized version of clang with vendor-locking on cargo online infrastructure and overly hardcoded build-scripts with inexplicable locking of modification via mandatory checksum checking) with bell and whistles & libraries from a third-party repository (cargo/pip) to build whole bunch of big fat shared libraries, that are not actually shared with anything, into sandbox for a single one-time use utility. It wouldn't be such a mess if it was not a mixed app of interpreted code + pre-compiled binary code that could only be compiled with the worst compiler in modern history due to being targetted at throwing whole Linux convention out to mimic worst parts of Windows, MacOS and Android software management.

[NiceneNerd]

Nothing about BCML is normal. The entire thing is a compromise and a hack, built progressively using whatever tools happened to be available in whatever way could be forced to work. And tons of dependencies are held back for reasons outside my control.

You complain about an awful lot of stuff, but none of it matters unless you want to volunteer to rewrite BCML from scratch.

[GingerAvalanche]

@v-fox You seem very intent on leaving py310 as your version, instead of installing py38 and piping the pip command through the 3.8 executable, which is the supported way of installing bcml.

[v-fox]

You seem very intent on leaving py310 as your version, instead of installing py38 and piping the pip command through the 3.8 executable, which is the supported way of installing bcml.

@GingerAvalanche I was using python 3.9 (both a recommended version AND 3.10, current distro version, for that supposedly Linux-centric software) for test with pipx, venv and Windows version in pip, so how about you get familiar with situation of the issues instead of making irrelevant excuses ? The fatal issues are with the pre-compiled binary and bad rust dependency, the way bcml is laid out just makes it almost undebugable and bit-rotting dependencies is just one consequence of that.

Nothing about BCML is normal. The entire thing is a compromise and a hack, built progressively using whatever tools happened to be available in whatever way could be forced to work. And tons of dependencies are held back for reasons outside my control.

You complain about an awful lot of stuff, but none of it matters unless you want to volunteer to rewrite BCML from scratch.

@NiceneNerd I'm complaining because, even after following all of your instructions and doing bunch of my own testing, it's now completely unusable, so I can't fix BOTW with a single mod that would make it orders of magnitude more playable because literally all methods of installation fail. You admit yourself that it was due to your design. Well, because of your choice of python/rust and third-party cargo packaging, it's almost impossible to debug and be fixed by users and distro maintainers, you have to fix it on the side of PyPi, be replacing the binary, and by the side of cargo, by I don't know what with the rust dependencies. I'm (and everyone except you) physically unable to do that as a user and distro packager due to how those third-party services work.

For now, I suggest figuring what bad compile options is going into the PyPi-packaged Linux binary, my bet is on avx2 in some statically linked dependency, like libz-ng. This likely be easier then figuring out cargo's hardcoded uncompilable dependency crap. Again, can't do anything about it without even knowing what versions and configurations of cargo/rust were YOU using.

[HGStone]

you can fix your problem by using Windows

[v-fox]

you can fix your problem by using Windows

Oh, fantastic. Another knee-jerk fanatical reaction ? Are we going to just do juvenile trolling here ?

It's "my problem" on discussion here, it's YOUR problem, as it is your issue tracker for your software to which you seem to be a contributor to. The author asked what is the Linux problem on his "developed primarily on Linux" software and I answered factually and honestly, no need to bring the circus around it.

Unless it's not clear, I actually fixed the original reported issue here about python dependencies and made it work on all version of python3, it's the binary that is the ultimate hurdle. Not like any facts matter to the cheerleading squad.

Also, the Windows installation of pre-compiled bcml also seems to be pulling numpy dependency that wants to compile something all the same. I've read up on complains on gamebanana and it seems not all is well there either. So how about keeping this discussion about software and not your emotional reactions to my personality as a messenger ? And don't go pulling ages old "but I'm helpful with my trolling" excuse, I've been around Linux community for 20 years, I've seen this "but Windows though" quip hundreds of times.

[HGStone]

ah yes, a contributor, I added the words "or info.json" on the install mod pop-up.

here's an idea, use python 3.8 through pyenv as recommended since 3.9 seems to only work for some people, which apparently you are not one of them.

[ArchLeaders]

You seem very intent on leaving py310 as your version, instead of installing py38 and piping the pip command through the 3.8 executable, which is the supported way of installing bcml.

@GingerAvalanche I was using python 3.9 (both a recommended version AND 3.10, current distro version, for that supposedly Linux-centric software) for test with pipx, venv and Windows version in pip, so how about you get familiar with situation of the issues instead of making irrelevant excuses ? The fatal issues are with the pre-compiled binary and bad rust dependency, the way bcml is laid out just makes it almost undebugable and bit-rotting dependencies is just one consequence of that.

Nothing about BCML is normal. The entire thing is a compromise and a hack, built progressively using whatever tools happened to be available in whatever way could be forced to work. And tons of dependencies are held back for reasons outside my control.

You complain about an awful lot of stuff, but none of it matters unless you want to volunteer to rewrite BCML from scratch.

@NiceneNerd I'm complaining because, even after following all of your instructions and doing bunch of my own testing, it's now completely unusable, so I can't fix BOTW with a single mod that would make it orders of magnitude more playable because literally all methods of installation fail. You admit yourself that it was due to your design. Well, because of your choice of python/rust and third-party cargo packaging, it's almost impossible to debug and be fixed by users and distro maintainers, you have to fix it on the side of PyPi, be replacing the binary, and by the side of cargo, by I don't know what with the rust dependencies. I'm (and everyone except you) physically unable to do that as a user and distro packager due to how those third-party services work.

For now, I suggest figuring what bad compile options is going into the PyPi-packaged Linux binary, my bet is on avx2 in some statically linked dependency, like libz-ng. This likely be easier then figuring out cargo's hardcoded uncompilable dependency crap. Again, can't do anything about it without even knowing what versions and configurations of cargo/rust were YOU using.

@v-fox this sounds like you are lodging a complaint for something you paid for, and therefore must work. Don't forget this is free software maintained and written in free time, it never needs to work nor needed to. It's a massive project, literally designed to do something that was never meant to be done.

If something doesn't work, you can't really blame the developers for doing, or not doing something for free, in their free time, people make mistakes, and it's not their job to fix them. They're trying their best to make everything work for a wide variety of users on different platforms, and have done an amazing job as far as I'm concerned, given what this software does, and requires.

As far as fixing your issue, try using python 3.7 or 3.8 and install using pip as recommended by @GingerAvalanche.

And sorry if I sound annoyed, I just find far too many people coming and complaining about the software they are getting for free, not to mention also getting free support. Remember, no one here is designated to help you.

It's "my problem" on discussion here, it's YOUR problem, as it is your issue tracker for your software to which you seem to be > a contributor to. The author asked what is the Linux problem on his "developed primarily on Linux" software and I answered > factually and honestly, no need to bring the circus around it.

And yeah, as HG just stated, he and I are just contributors cause we found a bug and fixed it. It doesn't make us part of some, non-existent "support team", we just like what the devs do, and wanted to help out.

[GingerAvalanche]

Unless it's not clear, I actually fixed the original reported issue here about python dependencies and made it work on all version of python3

It actually wasn't clear, since I make it a point not to read walls of text when it's clear the author is angry at me. Much better for my mental health to not subject myself to that.

Since you seem so proud of your 20 years of Linux community membership, you could do what Linux is famous for, and leverage the advantages of open-source development by contributing a PR.

Either way, this issue was solved days ago and has become little more than mud slinging at this point, so I'm closing it out.