Python 3.10

[rnbwdsh]

Following the readme on a current python 3.10 system (i.e. arch, fedora, ubuntu 22.04) fails for multiple reasons

I.e. a problem with the custom simpleeval dependency

      error in simpleeval setup command: use_2to3 is invalid.

And ignoring that

ERROR: Could not find a version that satisfies the requirement sip==4.19.8 (from versions: 5.0.0, 5.0.1, 5.1.0, 5.1.1, 5.1.2, 5.2.0, 5.3.0, 5.4.0, 5.5.0, 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.1.0, 6.1.1, 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.5.1, 6.6.0, 6.6.1, 6.6.2)

However, there is no reason to stick to python 3.6 compatibility as the fbs-dependency is just artificially limited to python 3.6 to sell pro-versions, with an explicit check. Simply the main, instead of via the fbs command already skips this check.

This update to 3.10 would also allow distributing the application via pypi or with proper packages for ubuntu, arch... without app-images, in way smaller sizes as no full python 3.6 has to be shipped. This would be nice for arm64 systems (new Apple devices), which can't handle the 64 bit .so files in the AppImage.

Additionally, the scaling seems off on my system, and I don't know if it's because of the app-image-isolation not picking up on my native hidpi display, or because of the old pyqt version. (Small: AppImage version from vial-appimage)

I built the PR #120 to fix this. Feel free to make any changes.

Also, I assume this mostly Closes #39

[xyzz]

However, there is no reason to stick to python 3.6 compatibility as the fbs-dependency is just artificially limited to python 3.6 to sell pro-versions, with an explicit check. Simply the main, instead of via the fbs command already skips this check.

That's not exactly correct. For example, building frozen packages with fbs failed the last time I tried updating to 3.10.

[rnbwdsh]

How exactly can I test the "build"? (assuming you are talking about the bundling of installers/app images/...) Is it just the stuff from https://github.com/vial-kb/vial-gui/blob/main/.github/workflows/main.yml ?

And do you have an error log on what exactly fails?

[xyzz]

Yes, running workflows on github and then testing produced executables on all 3 operating systems should work.

[rnbwdsh]

I'm not an expert on github actions/CI stuff, but i think I got it now (not sure how to test it?).

In my local system, the fpm (required by fbs) wasn't in the path by default, leading to a binary not found and one other check in fbs, but for now it should work.

As some changes to fbs accumulated (removing the unnecessarily low versioned pins, that in the case of pyinstaller), i forked the repo to adapt it. I'd be happy to give some other vial devs access to it, or you fork my fork. Autoupdating is enabled via github actions.

[xyzz]

You should be able to run github actions on your forked repo, I think you need to go into settings and push a button to enable them. After that, you can download and test the 4 executable files it produces. In any case, I just went and approved the run for https://github.com/vial-kb/vial-gui/pull/120

[rnbwdsh]

Thanks for the awesome support so far!

Got it all running on my github, but in the Windows Installer .nsi I got (after removing the output suppresion in my forked fbs)

Plugin not found, cannot call ShellExecAsUser::ShellExecAsUser
Plugin directories:

Which lead me to comment out

; Function LaunchLink
;   !addplugindir "."
;   ShellExecAsUser::ShellExecAsUser "open" "$SMPROGRAMS\${app_name}.lnk"
; FunctionEnd

Logs

Now I also squashed the commit, as the trial and error produced a lot of commits.

[xtaran]

Got everything built with Python 3.10 by not using the hardcoded versions in requirements.txt but the newest versions (by removing most == version constraints, especially those I could satisfy with Debian packages), but in the end starting the application via fbs failed with this error message:

The free version of fbs only supports Python 3.5 and 3.6.
Please obtain fbs Pro from https://build-system.fman.io/pro.

This is ridiculous. There is no Python 3.5 or 3.6 anymore in any current Linux distribution, so this tool is defacto unusable these days. Even Debian Stable from last year has Python 3.9.

So I just edited venv/lib/python3.10/site-packages/fbs/__init__.py, and added comment characters in front of these lines:

#    if sys.version_info[0] != 3 or sys.version_info[1] not in (5, 6):                                                                                        
#        raise FbsError(                                                                                                                                      
#            'The free version of fbs only supports Python 3.5 and 3.6.\n'                                                                                    
#            'Please obtain fbs Pro from https://build-system.fman.io/pro.'                                                                                   
#        )                                                                                                                                                    

Afterwards Vial ran totally fine for me with Python 3.10 on Debian Unstable.

So why are there so many unneeded or even harmful version constraints in requirements.txt? And why does nobody patch out this ridiculous version constraint from fbs? It's under GPL after all.

[rnbwdsh]

That's what I did with my fork (already in the PR, see this line ) - exactly for the reason you mentioned: It's GPL. I also thought about creating a fbs-free on pypi, but I don't want to maintain that or get into legal battles with a person living literally in the same country as me, and therefore realistically being able to sue me, lol.

I think the original guy noticed that his project is popular/useful so he introduced the "pro version" to "upsell" - with the intentionally ridiculous 3.6 requirement in May 2021. - of course he has no interest in improving the free version, if he can sell 800€ licenses to NASA and books.

But in general, no version pinning at all is a security accident waiting to happen with the current supply chain attacks (tbf: mostly on npm/node) - but I updated everything to what my arch deems "newest".

[xtaran]

That's what I did with my fork (already in the PR)

Ah, sorry, missed that part.

But in general, no version pinning at all is a security accident waiting to happen with the current supply chain attacks (tbf: mostly on npm/node) - but I updated everything to what my arch deems "newest".

Sorry, but IMHO hardcoding library versions is worse because those npm-style issues are just issues with the community itself, not with the software. These don't happen if you e.g. use python libraries provided by your OS. Not allowing security updates of the used libraries is IMHO the bigger threat. (And this is also a common issue with containerized application packages like AppImage or Docker. Nobody cares about security updates of the embedded libraries.)

[rnbwdsh]

I edited in the exact line in the prior comment, as it's somewhat hidden, thank you for reminding me to pointing that out.

I also think it's somewhat annoying, but version pinning is considered "industry standard good practice" in "professional enterprise software development" - at least for "leaf dependencies", so stuff that you don't expect others to import too.

If you want to go against it, a rigorous nightly testing build system with tests, dep-bot and other overly complex CI/CD mechanisms should be set up to check if none of the janky 0.* requirements broke their API - which isn't worth the hassle IMO (especially because it also needs to be done for the fbs fork too, to be really all-bleeding-edge)

But I'm not a core maintainer, of vial so it's not my problem/decision how to handle potential future versions breaking. But I'd highly root for at least being 3.10 compatible for the reasons you mentioned - and because installing secondary python versions on a system to develop for vial is a pain.

[KraXen72]

you could fork fbs one commit before he introduced the paid version and you're good if i understand correctly. like gpl licence allows forking/using the code as long as the resulting thing is foss, which vial-gui is.

[rnbwdsh]

I forked and rolled back the one "wrong" commit, otherwise having the newest version with the newest dependencies, instead of forking directly at that commit and missing all the work since 2019. Exact lines, commits, etc. linked in the stuff above.

Any update if we can merge, or if not, why? This is open since ~30 days and done since ~20, and I rebased the branch once already.

[KraXen72]

sorry i don't really get what you did / tried to explain in the last comment lol.

(i am not a main contributor so i cant greenlight this)

[xfo-0]

I ran into the scaling problem after already having it installed and working normally prior but by alternatively exporting the environment variable QT_SCALE_FACTOR=1 and QT_FONT_DPI to match my screen's resolved the issue.

[mitchcurtis]

I'm trying to get this project set up to contribute some patches and ran into the first error you got:

$ pip install -r requirements.txt
Collecting hidapi
  Cloning https://github.com/vial-kb/cython-hidapi (to revision 88d8983b3dc65b9ef84238abe3f46004b0ef2fd0) to c:\users\mitch\appdata\local\temp\pip-install-boz1vedk\hidapi_27d1bef6826c4fcabbd640905ba7465e
  Running command git clone --filter=blob:none --quiet https://github.com/vial-kb/cython-hidapi 'C:\Users\Mitch\AppData\Local\Temp\pip-install-boz1vedk\hidapi_27d1bef6826c4fcabbd640905ba7465e'
  Running command git rev-parse -q --verify 'sha^88d8983b3dc65b9ef84238abe3f46004b0ef2fd0'
  Running command git fetch -q https://github.com/vial-kb/cython-hidapi 88d8983b3dc65b9ef84238abe3f46004b0ef2fd0
  Running command git checkout -q 88d8983b3dc65b9ef84238abe3f46004b0ef2fd0
  Resolved https://github.com/vial-kb/cython-hidapi to commit 88d8983b3dc65b9ef84238abe3f46004b0ef2fd0
  Running command git submodule update --init --recursive -q
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Collecting https://github.com/danthedeckie/simpleeval/archive/41c99b8e224a7a0ae0ac59c773598fe79a4470db.zip (from -r requirements.txt (line 10))
  Using cached https://github.com/danthedeckie/simpleeval/archive/41c99b8e224a7a0ae0ac59c773598fe79a4470db.zip
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'error'
  error: subprocess-exited-with-error

  python setup.py egg_info did not run successfully.
  exit code: 1

  [1 lines of output]
  error in simpleeval setup command: use_2to3 is invalid.
  [end of output]

How did you work around it? I've seen other bug reports online where people have changed the version used, but I'm not sure how to do that (all of the ones I saw used different repos) nor which version to set it to, being fairly new to Python development.

[dwlocks]

In https://github.com/vial-kb/vial-gui/issues/39, I updated to py 3.12, QT5.latest, and removed fbs. So it's another, more-up-to-date way to close https://github.com/vial-kb/vial-gui/issues/39, but without requiring a patched version of a piece of faux-open source software.