Hi all,
I'm the maintainer of pyfa [1][2], a tool for EVE Online players. I was wondering if I could get some advice on how to include an arbitrary version of a Python library into the package?
The problem is that the current version of python-wxpython in community has a bug that causes the latest version of pyfa to crash, and the pyfa developers have set a hard requirement of wxPython == 4.0.0b2 [3] (the issue will apparently by fixed in 4.0.2).
What's the best or most elegant way to handle this?
The only thing I can think of is using pip to install this version into my $pkgdir and setting PYTHONPATH in the startup shell script to force pyfa to use the bundled version. However, I'm not sure of this and would like any pointers or better a better way to handle it.
Cheers.
[1] https://aur.archlinux.org/packages/pyfa/ [2] https://github.com/pyfa-org/Pyfa [3] https://github.com/pyfa-org/Pyfa/blob/master/requirements.txt
On 05/15/2018 12:35 AM, Simon Perry via aur-general wrote:
Hi all,
I'm the maintainer of pyfa [1][2], a tool for EVE Online players. I was wondering if I could get some advice on how to include an arbitrary version of a Python library into the package?
The problem is that the current version of python-wxpython in community has a bug that causes the latest version of pyfa to crash, and the pyfa developers have set a hard requirement of wxPython == 4.0.0b2 [3] (the issue will apparently by fixed in 4.0.2).
What's the best or most elegant way to handle this?
The only thing I can think of is using pip to install this version into my $pkgdir and setting PYTHONPATH in the startup shell script to force pyfa to use the bundled version. However, I'm not sure of this and would like any pointers or better a better way to handle it.
Cheers.
[1] https://aur.archlinux.org/packages/pyfa/ [2] https://github.com/pyfa-org/Pyfa [3] https://github.com/pyfa-org/Pyfa/blob/master/requirements.txt
This depends on if you want user-friendly or more "pacman-ish".
The "proper", "pacman-ish" way to handle it is to specify the explicit version in the depends array (even if it's not available in the current repository "snapshot").
The "user-friendly" way is to create a second package, e.g. python-wxpython-400b2 or something, and make that a dependency. The issue there is it is a strict requirement of the AUR that you not reproduce any packages already in the official repositories so that would not, I'd say, make this a valid option.
However, my PERSONAL recommendation is to just hold out for 4.0.2 and sticky a comment on your package that yes, it currently fails to build with the current version of wxpython and that upstream wxpython will be fixing it in a release coming soon.
You certainly could use a bundled custom pythonpath (*technically* you wouldn't even need to use pip, and just include a static build as a source tarball or something if you wanted to remove the pip dependency), but the problem is once 4.0.2 hits arch repos, you'd have to undo all that.
So, up to you, but I'd recommend just waiting. wxpython's pretty quick with new releases of revision/branch change releases. The 4.0.x branch seems to see a lot of recent activity[0].
[0] https://github.com/wxWidgets/Phoenix/tree/wxPy-4.0.x
On 05/15/2018 02:27 AM, brent s. wrote:
The "user-friendly" way is to create a second package, e.g. python-wxpython-400b2 or something, and make that a dependency. The issue there is it is a strict requirement of the AUR that you not reproduce any packages already in the official repositories so that would not, I'd say, make this a valid option.
Then we're incredibly lucky you don't set policy, because you're totally entirely wrong.
I suggest you go looking sometime and see just how many packages in the AUR are foo-$oldversion. Then for bonus points look at how many *official repository* packages are like that.
You certainly could use a bundled custom pythonpath (*technically* you wouldn't even need to use pip, and just include a static build as a source tarball or something if you wanted to remove the pip dependency), but the problem is once 4.0.2 hits arch repos, you'd have to undo all that.
Once 4.0.2 hits the Arch repos, any solution of any sort would need to be undone, whether that is pinning the version to some external $oldversion compat package in the AUR or bundling in a custom PYTHONPATH.
aur-general@lists.archlinux.org