Closed leycec closed 6 years ago
Note to self: an upstream issue should be opened. Not that it particularly matters. I'll probably do it tomorrow, if nihilistic cynicism doesn't take me first. </sigh>
@leycec I really understand your frustrations, but yes, you should definitively not report this here and instead take this upstream – and you can always cc me there and we'll have the discussion where the devs can also join in.
I'm setting up gerrit today so that I can quickly send patches their way, and not just open new bug reports. I think we're being a little unfair to the PySide2 devs not doing this and instead ranting in the comments of this project (no offence intended towards you, I do this all the time). If our patch is not 100% perfect, it'll be perfect once it goes through their review. We can always ask for their suggestions if we don't understand the big picture of things and just force a patch through much more quickly since we have personal/corporate/educational interests in doing so.
I once did contribute to PySide2 and it wasn't painful or time consuming at all. I just remember it was cumbersome to read up on how to get started with gerrit for PySide2 contribution. I might have to write down how I did it on my blog so I'll be able to remember it later on... (since I have now forgotten how to get set up and how to submit a patch).
Adding; your issue not something that I particularly is having problems with, which explains my luke-warm response to you... sorry.
Hey, no worries. Submitting Gerrit patches absolutely is the ideal approach. Sadly, I lack the time, motivation, or resources to "do it right." Upstream devs are much better positioned to resolve this sort of thing. It is, after all, their job; it's what they're ostensibly paid to do.
Doing this right really entails installing, maintaining, and testing patches on both the 5.6
and 5.9
branches and hence installing multiple concurrent versions of Qt, LLVM, and <insert-who-knows-what-here>
. It is unfathomable dependency hell.
I'm also not entirely confident that the sed
expression embedded above is entirely safe in the general case, as setup.py
already successfully installs these commands. Passing a scripts
keyword listing these commands will reinstall these commands – possibly over the existing installed commands or possibly elsewhere, possibly with incorrect permissions or ownership. You really don't want to do both, which means that the existing approach taken by setup.py
to install these commands should ideally be replaced by the scripts
keyword-style approach delineated above. That's the right way. Again, the core issue is that their setup.py
script is balls crazy and non-trivially difficult to maintain safely.
I was hoping for a quick GitHub fix – but, hey, that's cool. I'll probably end up manually cloning, compiling, and installing pyside2-tools
within our client-side installation scripts. It's not ideal, but I simply need this to work. Months of work are in jeopardy of being flushed all away.
I'm also not entirely confident that the sed expression embedded above is entirely safe in the general case, as setup.py already successfully installs these commands.
I definitively understand your perspective. I would argue the same way. But I think that if you are the driving force behind this having to be changed, that's what's required in this case. The devs (or me) doesn't feel that his particular issue is a priority, but you do.
So during a review, I'm sure you'll get enough info from them to understand what to do or not to do, and they'll most likely pitch in to help guide the patch get implemented in the finest way possible, fitting with the grander schemes of PySide2. At least, that's what I would assume.
I wrote a quick overview on how to get set up with Gerrit, you may want to check it out: https://fredrikaverpil.github.io/2017/09/30/contributing-to-pyside2/
I was hoping for a quick GitHub fix
Feel free to file a PR here, no problem! If your sed works, I'm guessing you'll be able to see that quite quickly in Travis? If you need a wheel to be built, you can just run the docker container locally.
Catch! Here's yet another problem you aren't paid enough to fix.
Unsurprisingly, the
pyside2-lupdate
andpyside2-rcc
commands installed by thepyside2-setup
repository don't appear to be bundled with binary wheels. Surprisingly, I actually need these commands for our million-dollar actually pennies multiphysics simulator to actually do anything.Because I'm the only human alive or dead who cares about this, I delved deep into the pustulating innards of
setup.py
– yes, thatsetup.py
– to see if I couldn't resolve this myself. In theory, I got pretty close. In actuality, I think I need you to clean up mysed
mess again. :sob:The underlying issue appears to be that
setup.py
fails to pass ascripts
keyword listing thepyside2-lupdate
,pyside2-rcc
, andshiboken2
commands to thesetup()
function call at the tail end of the file. If my reading of thebdist_wheel
subcommand is correct (it's probably not), passing this keyword the correct list should suffice to resolve this issue. Maybe?These commands are executable binaries rather than Python scripts and hence cannot be appended to the existing
entry_points/console_scripts
list. Instead, the Command Line Scripts section of the Python Packaging documentation suggests use of thescripts
keyword:On POSIX-compatible platforms, lines 961 through 970 of the
prepare_packages_posix()
method insetup.py
install these executables from the repository-localpyside-package/PySide2
directory into a system-wide executable directory – typically,/usr/local/bin
. Assuming these executables also reside in the former directory atbdist_wheel
building time (I'm half-certain they do), we might consider replacing:To do so, the following
sed
statement* might have the desired effect: * completely untested, likely brokenClearly, this is yet another critical upstream issue. Since upstream is out to lunch in the Bavarian Alps, I wonder if we might be able to tag-team this one. I know you're terrifyingly busy, but would you mind giving the above a go at some point?
I'd do so myself... if not for my intransigent laziness and desire to sleep tonight.