Search Criteria
Package Details: deepqt 1.1.7-6
Package Actions
Git Clone URL: | https://aur.archlinux.org/deepqt.git (read-only, click to copy) |
---|---|
Package Base: | deepqt |
Description: | Harness the power of the DeepL API with this friendly user interface. Translate plain text and epub files. |
Upstream URL: | https://github.com/VoxelCubes/DeepQt |
Keywords: | deepl glossary python translation |
Licenses: | GPL |
Submitter: | VoxelCubes |
Maintainer: | VoxelCubes |
Last Packager: | VoxelCubes |
Votes: | 2 |
Popularity: | 0.009855 |
First Submitted: | 2022-09-15 22:47 (UTC) |
Last Updated: | 2024-02-22 15:09 (UTC) |
Dependencies (7)
- pyside6
- python (python37AUR, python311AUR, python310AUR)
- python-beautifulsoup4
- python-pipx (python-pipx-gitAUR)
- python-pyxdg
- python-pip (make)
- python-setuptools (make)
Latest Comments
1 2 Next › Last »
VoxelCubes commented on 2024-02-25 13:20 (UTC)
Hello again!
Hm, I don't understand what you mean with "Can be down programmatically in package()." Do you mean "can be done" or "can be reduced"? Wouldn't that mean, that you claim to use certain pacman packages in depends, but then actually change it? That just sounds shady to me.
The idea with pipx is that it installs a virtual environment, so that it doesn't interfere with your system's site packages. Since version 1.3 you can give it read-only access to system site packages, so what I did was move as many of the pip packages to be installed with pacman as proper system packages as is viable. Then a few remaining ones (like the python-deepl package, which has a bad gpg key) are pulled in by pipx and installed in the isolated virtual environment. That way they can be properly cleaned up by pacman when uninstalling but don't mess up your python packages.
Python packages aren't installed by hash, but by name, and packages that do include compiled code, like PySide6 (which is I think the only one?), will automatically get the correct version for your arch installed. That's what's nice about having it as a source package like this. In fact, for PySide6, it's pacman handling that one in the same way (and that does have an ARM package).
So really, it is independent, as long as the dependencies are too, but that will depend on the individual system.The remaining python packages are all without binaries afaik. But I don't have an ARM system to test on.
But if all you want is for me to change the label to be "x86, arm" or whatever the proper syntax is, I could do that too. Dunno how good RiscV support is.
Hey, if you can figure out a way to improve the build (as long as it doesn't start compiling modules for tens of minutes) that would be great. Or in that case, this here could be renamed the "-bin" alternative. If you need a full list of dependencies, I have a flatpak manifest listing everything with hashes. You can find it though flathub.
dreieck commented on 2024-02-24 19:55 (UTC)
Local models is great!
If the build script pulls in stuff via pipx that is not already locally installed, and not pulls in what is already locally installed, the
depends
array must be adopted to contain what it actually depends on what is locally installed. Can be down programmatically inpackage()
.And if the build script downloads binaries and installs them as part of the package, then this is not an
any
package anymore. Otherwise you need to make sure that those binaries are installed as dependencies.Hm, I am tempted to make a non-pip package of this, having everything pre-defined as dependencies, and making the dependencies, too. I think I won't right now because of the work involved (I too easily waste my time with AUR).
VoxelCubes commented on 2024-02-22 22:20 (UTC)
Ah, I see, @dreieck.
I myself don't distribute any binaries, it's all pure python, so my package itself is fully arch independent. It just depends on what Pyside6 supports, but that's entirely out of my control, and now properly handled by pacman, as it should be.
As for the cleanup in prepare(), as my comment describes, it's a temporary measure to fix my retarded mistake I made with packaging previously. Pipx (which is not the same as pip) installed deepqt into an isolated venv inside the user's ~/.local, which means that pacman couldn't actually clean it up when uninstalling. So you were stuck with the mess I had created if you didn't notice that, wasting a few GB of space. Hence my effort to at least ensure anyone updating one or two versions later will automatically get that mess removed. It isn't a matter of conflict, just a way to fix my mistake as best I can, I'm very sorry for not noticing beforehand.
I'll remove the check for the next version, I agree that it shouldn't be there longer than necessary.
Now that most of the dependencies are handled by pacman, this package is less than 30MB, last I checked, without the possibility of creating a big mess.
And speaking of the next version, I'll be working on that next month. I have big plans to expand deepqt's capabilities to locally run models.
Cheers, and thanks again for all the help!
dreieck commented on 2024-02-22 18:48 (UTC)
Ahoh @VoxelCubes,
thanks for the headup.
Regarding
arch
: If you install binaries and support several architectures, you must list all supported architecutures in thearch
array explicitly.arch=(any)
is only for scripts or datafiles, not executable binaries.pipx uninstall deepqt
inprepare()
must be removed.PKGBUILD
must never mess with stuff outside$srcdir
or$pkgdir
. You can still check for possibly conflicting files and display a warning, but not mess with what the user might have done on the system in any other means!I have not tested the package any further yet, because I for now refrain from downloading possibly big stuff.
VoxelCubes commented on 2024-02-22 15:25 (UTC)
Thank you @dreieck the friendly triangle! I found out that the root of the issue was me having a stale DeepQt.desktop in my ~/.local/share/applications folder from when I was still incorrectly installing this. My retarded packaging back then didn't make proper use of the pkgdir, so when I uninstalled my old version, it left garbage like that behind. Now that it's gone, it falls back to the actual desktop file I have installed with the broken path, hence I now see the issue. It's my fault for not cleaning up properly, so thank you very much for letting me know!
So, with this new version, I make use of the new features in pipx since version 1.3 that everyone should now have, which lets you use system site packages to reduce the size of the pipx install. This means I could now specify proper packages for most of the python dependencies, especially the heavy ones like PySide. Some don't have packages, or do but they are broken, so pipx installs what is missing in a virtualenv in the /opt/ folder. I do this because I don't have the time to maintain 10 or more tiny python packages for the aur, and bug other maintainers to keep their broken ones up to date, and since python packaging is so terribly broken, this will provide the most stable experience.
Note on pyside being installed with pip: even with the old version, pip will automatically download the arch-dependent version, so arm was always supported.
I tried using prepare(), but that didn't place the files inside the fakeroot pkgdir, so that's a dealbreaker. According to the wiki, prepare is for unpacking archives and stuff, so I don't see why that should be used here.
Thanks again, hopefully it now works!
dreieck commented on 2024-02-21 21:25 (UTC) (edited on 2024-02-21 21:26 (UTC) by dreieck)
Directly calling
opt/pipx-deepqt/venvs/deepqt/bin/deepqt --help
(also, without--help
) fails withIt's shebang line also points to something in the temporary build directory, not the installation directory:
This package needs fundamental fixing.
Regards!
dreieck commented on 2024-02-21 21:23 (UTC)
/usr/bin/deepqt
is a symlink tomakepkg
's$BUILDDIR
, not to the installation directory, and thus broken after build finished and temporary build directories cleaned up:Regards and thanks for maintaining!
dreieck commented on 2024-02-21 21:22 (UTC) (edited on 2024-02-21 21:29 (UTC) by dreieck)
Why does it install it's own Qt6 (and since it does,
arch=(any)
is wrong since it ships binaries!)?Can you depend as much as possible on system libraries, please, to keep the package clean?
It is over 500 MiB big!, thats much too huge for a simple UI that does API requests to an external service.
The precompiled self-containing upstream Windows release .exe file is only 53.6 MiB big -- 1/10 of the size of this package!
Regards!
dreieck commented on 2024-02-21 21:16 (UTC)
Your
PKGBUILD
downloads (large amount of) stuff inpackage()
!This must not happen.
Please use
prepare()
for stuff you cannot handle via thedepends
array and thesource
array.(Note, for python packages it is usually much cleaner to not use pip but to add the dependencies to the
depends
array, maybe create the necessary packages. And then build withpython -m build
and package withpython -m installer
.)VoxelCubes commented on 2023-12-18 00:54 (UTC)
I have updated the packaging to let pipx install in /opt/pipx instead of the ~/.local/pipx, so that it will be properly uninstalled if you uninstall the package, and be system-wide.
Please perform a
pipx uninstall deepqt
before or after updating this package to clean up the previous version. (by default it will remove the one in the home folder, you would need to use the environment variablesPIPX_HOME=/opt/pipx PIPX_BIN_DIR=/usr/local/bin
to interact with the pipx install used by this package, which won't be necessary.)Sorry for the inconvenience.
1 2 Next › Last »