gentoo
net-misc/onedrivegui: fixed
- Fixed installation of the package
- Removed unwanted and unused files from the package
- Fixed package to work as a module: now main interface can be started by a shortcut or by python -m
- Limited to single python version only
- Other minor fixes
This PR does not drop existing ebuilds, just an additional revision is added (should be easier for users to rollback if anything goes wrong). I use single python version. This is a python application, actually. Makes a little sense to have several python versions of the same application in parallel (3.12, 3.13 etc.). This PR rely on standard python installation mechanics. Should be easier to maintain. The application is updated to work as a module, so now it can be stated by any of three ways:
- Standard small wrapper, installed automatically
- python -m OneDriveGUI
- starting main python file directly.
Any of the ways works just fine, providing additional flexibility.
By using standard installation mechanics, result is automatically byte-compiled with several optimisation levels. With limited to single python version, it is easy to fix shebang in the main file, which gives more correct result.
Additionally, I removed unused files (looks like some old leftovers) and fixed image reference in one file.
Run-tested on my PC.
This PR does not drop existing ebuilds, just an additional revision is added (should be easier for users to rollback if anything goes wrong).
Given that the current version is uninstallable there's not really anything to roll-back to.
I use single python version. This is a python application, actually. Makes a little sense to have several python versions of the same application in parallel (3.12, 3.13 etc.).
This is not actually how the python ecosystem does things. There, you install an application/library for some python version, putting all the source in a python-implementation specific directory. So, even if a application is mainly intended to be used as a program, it is still a multi-implementation python package.
This PR rely on standard python installation mechanics. Should be easier to maintain.
This would ideally be fixed upstream, and then we package a functioning application, rather then the current situation
This PR does not drop existing ebuilds, just an additional revision is added (should be easier for users to rollback if anything goes wrong).
Given that the current version is uninstallable there's not really anything to roll-back to.
OK. Should I include drop of it into this PR?
I use single python version. This is a python application, actually. Makes a little sense to have several python versions of the same application in parallel (3.12, 3.13 etc.).
This is not actually how the python ecosystem does things. There, you install an application/library for some python version, putting all the source in a python-implementation specific directory. So, even if a application is mainly intended to be used as a program, it is still a multi-implementation python package.
Right. It makes sense when the module is used by other python applications or modules: they must be installed for the same python version otherwise they will not work. As other python modules could be limited to some specific python versions, some modules could be kept for several versions. Here is an application, part of it is not used by other python modules. Having multiple versions of this application is just a waste of disk space. User will use only one version anyway. There is no way to use both versions simultaneously and unlikely any user would run 3.12-based version at the morning and 3.13-based version at noon. When user will switch main python version to the next one, it will re-merge this application again.
Also, it is problematic to use python_fix_shebang for python multi-version: sources cannot be patched, as they are reused to build every python version. image cannot be patched as then the file will not match byte-compiled version.
Single python version simplify it.
This PR rely on standard python installation mechanics. Should be easier to maintain.
This would ideally be fixed upstream, and then we package a functioning application, rather then the current situation
Yep, ideally. Keeping large local patches is always bad. For now I'm just sharing my work with others. Until (and if) it is up-streamed, we need to have patches anyway, so no choice now. If patches play nicely with gentoo users, I'll try to upstream them.
One more argument for single python version: DE menu icon/shortcut will start always one version only. Very unlikely that user would start manually another version..
However, if this point is fundamental, I can remove "single version" enforcement (together with shebang fix, which is not really important).
However, if this point is fundamental, I can remove "single version" enforcement (together with shebang fix, which is not really important).
I don't think it's that important. The biggest reason for it is because in the Gentoo python ecosystem, multi-impl packages can not depend on single-impl packages. Like you said, though, it's very unlikely that we will end up having packages depend on onedrivegui, in its current state at least. My main point that, since there's no argument for or against it, picking the standard multi-impl was more desired. I wont' insist on it, again, I'm happy with any approach
One more argument for single python version: DE menu icon/shortcut will start always one version only. Very unlikely that user would start manually another version..
The multi-implementation is pretty much completely transparent for a properly packaged python package. All impl-independent files are installed in some impl-specific like /usr/share/man or /usr/share/applications and the gentoo eclasses takes care of figuring out which impl is to install those. (The algorithm lets the most preferred python implementation install them. most desired here means the last value of the _PYTHON_ALL_IMPLS array in python-utils-r1.eclass)
A user then can just run somebin and have the app start like normal, no matter for how many implementations the application has been installed. If a user wants to launch the app through some other python version they could do python3.13 -m someapp.main but that assumes that the application actually has a main entry point.
I haven't done that many python packaging so this is how I imagine the situation. https://projects.gentoo.org/python/guide/eclass.html's first line paragraph says using python-single for scripts and python-multi for modules.
Also, it is problematic to use python_fix_shebang for python multi-version: sources cannot be patched, as they are reused to build every python version. image cannot be patched as then the file will not match byte-compiled version.
Yes,the proper fix would be installing a separate python executable (through python_doexe) that will be called by the right.
I did try to write a multi-impl ebuild and I basically got this https://github.com/gentoo/dlang/blob/dfdc4bbcd97b0716eae4873204b779e8167803b1/net-misc/onedrivegui/onedrivegui-1.1.1-r2.ebuild#L34-L51 which isn't that much. It's just enough to get the application working so it doesn't do as much as your approach.
Having multiple versions of this application is just a waste of disk space. User will use only one version anyway. There is no way to use both versions simultaneously and unlikely any user would run 3.12-based version at the morning and 3.13-based version at noon.
Having a multi-impl package installed for 1 implementation shouldn't be that much more compared to having a single-impl package
I do want to mention that I don't know what to do with the 2 PRs trying to do the same thing. I think I prefer #136 because it also fixes onedrivegui-bin (is currently trying). I'm also kinda biased since it's my code for onedrivegui getting merged.
It would be a lot easier to decide if one of you went and fixed the build system upstream and came back with a nice and clean ebuild.
It's also a possibility to merge your changes for onedrivegui and @MrDuartePT's for onedrivegui-bin.
I do want to mention that I don't know what to do with the 2 PRs trying to do the same thing. I think I prefer #136 because it also fixes
onedrivegui-bin(is currently trying). I'm also kinda biased since it's my code foronedriveguigetting merged.It would be a lot easier to decide if one of you went and fixed the build system upstream and came back with a nice and clean ebuild.
It's also a possibility to merge your changes for
onedriveguiand @MrDuartePT's foronedrivegui-bin.
I think for now lets use the ebuild from #136 (sorry if seems biases), because it uses the distutils-r1 eclass standard. But if the setup.py and cfg get accepted upstream we can come back to this PR and use that instead.
Also @Karlson2k you already patching the files why not try to see if get accepted upstream.
Once you took another PR, I'd suggest to get clean-ups and fixes from this PR. Namely:
You are installing unneeded and broken files without these fixes.
It would be a lot of help for me if you could rebase your PR against the current ebuild.
Because I don't want to turn down you you changes simply because there was another PR a few days prior to yours if you address the changes I've requested against the onedrivegui ebuild as it was when you created this PR I'll backport your fixes manually.
Regardless of what you do I want to express that I am grateful for your interest and, if your changes targeted something that I had more interest in, I think I would have been more amiable :)