#pyqt | Logs for 2019-01-09

Back
[00:16:22] -!- mandeep has joined #pyqt
[01:49:06] -!- kallesbar has joined #pyqt
[02:18:56] -!- Mrokii has quit [Ping timeout: 268 seconds]
[02:35:04] -!- Mrokii has joined #pyqt
[03:36:38] -!- BPL has joined #pyqt
[04:01:42] -!- anqxyr has joined #pyqt
[04:05:23] <Mrokii> Okay... I have a new problem with my file dialog. In another place, I had used "getExistingDirectory" to let the user select folders. However, that convenience function doesn't let me change the name-filter, so that the image-files are shown also. For the file-dialog I worked on yesterday, I tried to let the user choose a directory but still display all the images in these folders. The "display" part works when
[04:05:26] <Mrokii> creating the file-dialog manually, but I can't choose directories, only files.
[04:05:45] <Mrokii> I guess I need to somehow add "directories" to the name-filter...
[04:19:40] -!- anqxyr has quit [Read error: Connection reset by peer]
[05:02:52] -!- Lauxley has joined #pyqt
[05:11:17] <Mrokii> What I'm trying to achieve is a file-dialog like with "getExistingDirectory", but with the ability to also show all images.
[05:18:04] <Mrokii> There must be some option I don't set correctly, as when I use "QFileDialog.getExistingDirectory" the button to select something is labelled "choose", but when I manually create a QFile-Dialog, that button os labelled "Open".
[05:30:22] <Mrokii> Okay, forget it. I was stupid. I used the "QFileDialog.Directory"-option in the wrong way. Now the file dialog works as it should, showing me images and directories and letting me choose directories.
[07:59:57] -!- russw has joined #pyqt
[10:16:03] <russw> altendky: sorry - I did see your dll stuff earlier... I just didn't have time to parse and respond
[10:16:21] <altendky> russw: no problem, just didn't want to leave you hanging after all the time you put in
[10:16:33] <russw> at this point I'm not actually sure that that pyqt5qmlplugin.dll can be portable :(
[10:17:44] <altendky> russw: about the maillist stuff i assume. how does it work at all if it's a hardcoded python path but we move it down into the chapter6 examples?
[10:17:46] <russw> at least not without specifying PYTHONPATH every time you use it with a python dir that doesn't exactly match the absolute path that python was in during compilation
[10:17:48] <altendky> kinda seems it can't be
[10:18:09] <altendky> russw: well, pyqt5qmlscene is exactly about setting the PYTHONPATH etc
[10:18:24] -!- Lauxley has quit [Remote host closed the connection]
[10:18:39] <russw> the path is absolute, so it grabs the site-packages from your python installation
[10:19:15] <russw> try running it from a virtualenv that has PyQt5, while the "parent" python (the one used for compilation) doesn't have it
[10:19:27] <russw> pretty annoying
[10:19:34] <altendky> russw: i would like to think that's my normal scenario, but i'd have to check
[10:19:46] <altendky> who knows what i did years ago...
[10:20:03] <russw> that is also my normal scenario, so I was confused at first
[10:20:12] <russw> then it turned out my parent python actually did have PyQt5 in it
[10:20:28] <russw> not sure why... probably an accidental install at some point
[10:20:36] <altendky> right
[10:20:50] <altendky> russw: so i shove sys.path into the beginning of PYTHONPATH https://github.com
[10:21:17] <russw> any idea what python37.lib contains (vs the .slo or .dll)?
[10:21:21] <altendky> russw: so whatever env pyqt5qmlscene is running in should get pushed onto qmlscene (maybe there's more to set, but at least that)
[10:21:41] <altendky> russw: .sol?
[10:21:58] <russw> the .lib is what configure.py is looking for, and that isn't moved over to a virtualenv
[10:22:03] <altendky> russw: the lib contains the interface i think and gets built into the application. the .dll contains the content
[10:22:28] <russw> wonder why it isn'
[10:22:31] <altendky> russw: well, for static the .lib would be the library. for dynamic, it'd be the interface
[10:22:33] <russw> t moved over, then?
[10:22:50] <altendky> russw: why would it be? afaik it gets statically built into the program being built
[10:22:55] <russw> ok
[10:23:14] <russw> so phil is statically linking the .lib in?
[10:23:22] <altendky> (note, been awhile since i've dones windows c programming and i'm no master)
[10:23:26] <russw> that doesn't make sense since without the .dll in the path nothing works
[10:23:35] <russw> same here
[10:23:51] <altendky> the .lib wouldn't substitute for the .dll
[10:24:11] <russw> not even if static linking while compiling pyqt5qmlplugin.dll?
[10:24:13] <altendky> it just gives you the things needed to build
[10:24:29] <altendky> hmm..
[10:24:36] <altendky> how big is the lib vs the dll
[10:25:03] <altendky> does the present pyqt5-tools not work in some scenario?
[10:25:35] <russw> dunno... I was skipping your tools and going with direct usage to figure out wth is happening
[10:26:31] <russw> but for sure it won't work if your <foo>plugin.py file expects to work within a virtualenv's set of packages that are not in the parent python
[10:26:47] <russw> I was about to confirm if liberal PYTHONPATH hacking could make it work
[10:26:58] <russw> in which case you could wrap that up, too
[10:27:00] <russw> gimme a minute
[10:27:32] <altendky> i do. i take the sys.path of the env that pyqt5qmlscene is running in and shove it into PYTHONPATH for the subprocess to qmlscene
[10:27:49] <altendky> and now, also the PATH (which is a bit abusive but...)
[10:27:55] <russw> the entire thing?
[10:28:46] <altendky> yeah, if it works we can tune it if we want :]
[10:30:16] -!- Siecje has joined #pyqt
[10:47:32] <russw> altendky: making incremental progress still... stuffing the full virtualenv's sys.pth into PYTHONPATH does help get through another error
[10:47:57] <russw> where, as before, knocking down one error to deal with the next is "progress" :)
[10:48:33] <altendky> would it be worth trying pyqt5qmlscene to see if it works for you? if so, you've got another reference
[10:48:53] <russw> altendky: current pypi release?
[10:49:18] <altendky> russw: i also shove sys.path into PATH (for the dll, again, yeah, lazy and overly broad)
[10:49:42] <altendky> russw: i didn't put it there yet https://ci.appveyor.com
[10:49:55] <russw> that I did not do... the current error may be on my end, though... need another few minutes
[10:49:57] <russw> then I'll try that
[10:50:09] <altendky> pick your version then artifacts then pass the url to pip
[10:58:49] <russw> ding ding!
[10:59:00] <russw> success... it was on my end
[10:59:21] <russw> so... liberal PYTHONPATH hacking should do it
[10:59:36] <russw> in my case, PATH itself did not need to be hacked
[11:00:37] <russw> altendky: I'll make a fresh virtualenv and try oen of your latest builds now
[11:01:20] <altendky> i believe i needed PATH changed for the python dll
[11:02:54] <russw> you do need that at least, but not the whole sys.path. You can probably get away with just adding os.path.dirname(sys.executable), since that is all I do.
[11:03:37] <russw> that is to get rid of the `plugin cannot be loaded for module "foo": Cannot load library` error
[11:04:05] <russw> (per the processmonitor snooping we did the other day)
[11:04:24] <altendky> i thought i tried that. perhaps i looked at the non-virtualenv situation and it was different
[11:05:18] <russw> well... it's all a bit of a mess, so you never know. But my incrementakl steps to get it working (with compatible plugin dll) are:
[11:05:23] <russw> (from scratch)
[11:08:15] <russw> 1) copy the pyqt5qmlplugin.dll to the correct plugin dir; 2) set QML2_IMPORT_PATH to the dir above it (plus whatever else you need); 3) ensure that the python dll is in the PATH; 4) add the full sys.path used by the virtualenv to PATH
[11:08:27] <russw> and then it works
[11:08:48] <russw> 4) is still inexplicable to me... no clue why phil would have hardwired that
[11:09:31] <russw> I planned to look into patching the pyqt5qmlplugin.dll compilation today to fix that, but with the liberal PYTHONPATH hacking working I'm less motivated
[11:09:33] <altendky> what else would you do? it's going to go to a random location
[11:09:49] <altendky> was 4) supposed to be PYTHONPATH?
[11:10:12] <russw> oops... yes. 4) was to PYTHONPATH, not PATH
[11:10:34] <russw> wht do you mean a random location?
[11:11:00] <altendky> the dll is going to go somewhere and that somewhere is at no specific relative path to any python anything
[11:11:18] <russw> what is happening is that the python code invokation happening in the plugin dll is hard-wired to use the path to the .lib that it the compilation's configure.py found
[11:11:22] <russw> ah
[11:11:32] <altendky> so either you provide no path for the python dll and require searching in all cases, or you let it work in the case where it is used in the original python
[11:11:36] <russw> I would check the current path
[11:11:51] <altendky> the current PATH?
[11:11:54] <russw> yes
[11:12:03] <altendky> isn't it doing that? that's why adding sys.path to PATH helps?
[11:12:11] <russw> just like DLLs do, and just like invoking python from the cmdline does
[11:12:17] <russw> no it is not doing that
[11:12:42] <altendky> so... it doesn't work without pyqt installed in the as-compiled python location?
[11:13:05] -!- AbleBacon has joined #pyqt
[11:13:12] <russw> right
[11:14:06] <russw> mainly because the sys.path that the plugin dll is using is the one that would be used by the python that was found during compilation
[11:14:20] <altendky> so i was testing in 3.7-64, i had just installed it. pip freeze from it gives pluggy/py/six/tox/virtualenv (iow, virtualenv got installed). it works
[11:15:28] <russw> not sure what you mean?
[11:15:31] <altendky> well, testing in an env from that
[11:15:58] <altendky> i mean that pyqt5qmlscene is working in a virtualenv and i never installed pyqt5 in the original python that env was created from
[11:16:23] <altendky> i can make then share a terminal session you could review (so many ways i could be mischecking i'm sure...)
[11:16:26] <russw> the main thing I saw yesterday was that the plugin dll, when it executes python code, was using a sys.path that was NOWHERE in my system path, or PYTHONPATH, or anywhere
[11:16:45] <russw> phil then confirmed that it uses the path found in configure.py
[11:16:45] <altendky> but it also read from PYTHONPATH?
[11:16:49] <altendky> plus random other stuff
[11:16:55] <altendky> 'random'
[11:17:02] <russw> I'm game for a session... that would be easier
[11:17:46] <russw> I would rephrase that into "core python code itself prepends os.environ['PATH'] to sys.path", so that is why we can hack it
[11:18:00] <russw> or rather, hack around the hard coding that the dll has
[11:18:22] <russw> the only hesitation I have is that I searched the dll for strings and did not see the path
[11:19:01] <russw> weirdly, I did see a reference to a 3.6 lib (I'm using 3.7)... not sure what that was about
[11:20:42] <altendky> well that was cool. mid sentence and my laptop powered off. not shutdown, just click and black
[11:21:29] <altendky> is starting from a pip freeze on the system python sufficient? then create an env from it etc
[11:21:37] <russw> I (regrettably) switched my laptop from debian to win10 a while ago, and weird stuff like that happens all too frequently :(
[11:23:37] <russw> if yoru system python has pyqt5 in it it will contaminate experiments a bit, but a fresh virtualenv is otherwise sufficient
[11:23:51] <altendky> right the freeze is to suggest it doesn't :]
[11:24:05] <altendky> once i get my system back mildly organized
[11:24:34] <russw> pipenv has been working great on windows, btw ... starting to be a fan
[11:25:36] <russw> no local wheel support is annoying, but that's a minor complaint
[11:38:34] <altendky> sorry, caught up in some real work stuff
[11:39:04] <altendky> no automated release process so you get random requests to go back and generate stuff from six month old builds
[11:40:28] <russw> I just assumed you used appveyor at work and that was why you used it for pyqt5-tools :)
[11:40:52] <altendky> actually we're 'in the process' of setting up our own phabricator + jenkins
[11:41:01] <altendky> but i do use appveyor for my work pyqt stuff
[11:42:15] <russw> speaking of appveyor, why is your QT_BASE_PATH 5.11.2 for your 5.11.3 builds?
[11:42:40] <altendky> because pyqt5 5.11.3 official wheels are for qt 5.11.2
[11:43:01] <altendky> https://pypi.org that's what the 5.11.2 in the filenames is
[11:44:46] <russw> ok
[11:44:53] <russw> that does leave me slightly confused
[11:45:34] <russw> I compiled my PyQt5 against a Qt 5.11.3, and my PyQt5.QtCore.QT_VERSION_STR is still 5.11.2
[11:45:37] <russw> ???
[11:45:56] <altendky> i dunno
[11:46:49] <russw> I didn't know (or had forgotten) that the third PyQt5 version number is not slaved to Qt's
[11:46:54] <russw> I guess that makes some kind of sense
[11:48:52] <russw> ok... my QT_VERSION_STR is because the fresh env I just made to test your release ended up pulling PyQt5 from pypi
[11:49:37] <russw> it's sad how confusing this all is (to me)
[11:52:06] <altendky> https://gist.github.com popped up a pie chart thingy
[11:52:13] <russw> altendky: does the free/open-source appveyor tier let you store that set of 149 MB wheels with no issue?
[11:52:35] <altendky> yup :]
[11:52:43] <russw> wow. sweet.
[11:52:44] <altendky> used to be indefinite, now 6 months. but that's global to appveyor
[11:52:51] <altendky> i know, travis sucks doesn't it...
[11:53:03] <altendky> though i do feel a bit bad when it comes to pyqt5-tools
[11:53:21] <altendky> gigabytes per build? :[ well, normally just hundreds of megabytes, but gigabytes for now
[11:56:35] <altendky> of course, as i point out that travis sucks i'm working on a tool to let us easily matrix python ci builds across travis on all of linux/osx/windows
[11:56:46] <altendky> (just a python installer really)
[11:59:38] <altendky> i guess i should really be showing if the python at the path that appveyor has it has pyqt5 installed
[12:00:35] <altendky> https://www.appveyor.com and i only have Python27 on my c root
[12:00:49] <altendky> so i think that's still a clean 'test'
[12:00:59] <altendky> russw:
[12:01:19] <russw> I was just testing your latest build... good news! It works.
[12:01:50] <russw> All I needed to do was set QML2_IMPORT_PATH as appropriate to include my import dirs that your code can have no clue about. Then tada!
[12:02:09] <altendky> or pass those paths as cli args :] or add to .env :]
[12:02:33] <russw> let me try...
[12:02:50] <altendky> mm, lemme check
[12:03:26] <altendky> if using .env, do note the DOT_ENV_DIRECTORY variable i inject https://www.appveyor.com
[12:03:29] <altendky> err
[12:03:32] <altendky> https://github.com
[12:03:52] <altendky> that way you can have paths relative to the .env file's directory (presumably it'd be at your project root or such
[12:05:13] <russw> two -p args worked great. I'll try .env as well.
[12:07:39] <russw> altendky: ok, so .env doesn't let you specify stuff inside it. you just stuff its dir into DOT_ENV_DIRECTORY?
[12:08:42] <altendky> russw: the wrappers inject the DOT_ENV_DIRECTORY variable such that you can use it in your .env file to specify env vars (like QML2_IMPORT_PATH)
[12:08:52] <altendky> are you familiar with .env files?
[12:09:04] <russw> nope
[12:09:15] <russw> looking them up
[12:09:22] <altendky> ah, they are basically bash files that assign env vars
[12:09:57] <altendky> so content might be `QML2_IMPORT_PATH=${QML2_IMPORT_PATH};${DOT_ENV_DIRECTORY}/path/to/my/qml`
[12:10:23] <altendky> that'll append c:\your\project/path/to/my/qml to any existing QML2_IMPORT_PATH you might have already specified in the env var
[12:11:00] <altendky> https://github.com
[12:11:22] <russw> yep... reading that page :)
[12:12:03] <altendky> so we've got various steps left to do or consider. 1) reduce artifact size (100mb limit or somesuch on pypi by default) 2) create an example qml 3) create a qml for automated tests 4) reduce the shotgun approach to PATH and maybe PYTHONPATH 5) don't profit because we are giving this away
[12:12:06] <russw> or rather, I'm distracted by reading "12-factor apps", but I'll get there :)
[12:12:33] <altendky> though there are valuable arguments against putting secrets in .env files (or env vars at all)
[12:12:33] <russw> did 5 really have to be called out? :)
[12:13:58] <russw> for 1), I feel like PyQt5 can just be a dependency and then do more liberal *PATH hacking to borrow PyQt5's files
[12:14:30] <altendky> i'd start with 'what tripled the size?'
[12:14:46] <russw> lemme unzip that and see
[12:14:58] <altendky> presumably the qml stuff, but what parts and are they needed
[12:15:46] <altendky> too bad i changed directory structure as i included the qml stuff. harder to diff against a smaller file. but maybe just start by checking the qml dir size. might be enough to explain the diff
[12:17:04] <russw> qml is huge... check this out (unpacked):
[12:17:44] <russw> https://bpaste.net
[12:18:14] <altendky> but we shouldn't need anything more than pyqt5 provides, right? so a lot of that must be unneeded
[12:18:20] <russw> 183 MB for QtQuick alone
[12:18:29] <russw> yep... that entrie dir is already with PyQT5
[12:18:48] <altendky> well, part of it. i've obviously got a lot more than they do
[12:19:19] <russw> lemme see
[12:24:36] <russw> it's mostly pdb files
[12:24:39] <russw> plus some misc stuff
[12:24:47] <russw> I'll get you a list
[12:24:48] <altendky> that'll do it
[12:28:39] <russw> here's the diff:
[12:28:41] <russw> https://bpaste.net
[12:28:52] <russw> sorry for the weird dir names, but the info is there
[12:29:10] <altendky> no prob
[12:29:19] <altendky> so the debug dll's and the pdb mostly
[12:29:47] <altendky> i can start with that and see where it gets us
[12:30:14] <altendky> if only it were .d.dll or something so i didn't have to worry about non-debug dll's that ended in d
[12:30:32] <altendky> like qtcanvas3d.dll
[12:31:41] <russw> here's the whole Qt dir:
[12:31:42] <russw> https://bpaste.net
[12:32:09] <russw> yeah, that naming convention isn't great, is it
[12:32:48] <altendky> any convention that merges things indistinguishably together is... well, i'll keep the cussing to myself
[12:33:44] <russw> the sibling dll will be around, so you can always check for things that differ only with a d suffix
[12:33:48] <russw> more code, but doable
[12:34:03] <altendky> that's the plan. it'll be mildy fun to make a tidy solution
[12:34:11] <russw> I hear you
[12:34:15] <altendky> without hardcoding the exception
[12:34:19] <russw> I often think stuff like that
[12:34:27] <russw> then curse when it ends up taking a full day
[12:34:31] <russw> :)
[12:35:45] <altendky> yeah, i'm trying to figure out how i want to handle https://github.com since they are super unresponsive and presumably won't be fixing anything or accepting PRs anytime soon. and i want to validate that my output files 'match' theirs and are also correct.
[12:36:07] <altendky> i mean really, you have a schema and you have a makefile to check it and... that many fail to pass?
[12:47:13] <russw> clearly not their priority
[12:48:01] <russw> sunspec.org is pretty neat, though
[12:48:07] <russw> are you in solar?
[12:48:12] <altendky> i made the main lib 2/3 (from just 2) a couple years ago. they ignored it, redid it themselves (weirdly), then left it almost working but not actually able to connect to a device because of a '' == b'' scenario...
[12:48:22] <altendky> https://epcpower.com
[12:48:44] <altendky> so we do supply modules to other people doing solar installations
[12:48:51] <altendky> power converter modules
[12:49:47] <russw> cool
[13:04:21] -!- kallesbar has quit [Quit: Konversation terminated!]
[13:26:22] -!- nitro25 has joined #pyqt
[15:11:09] -!- mandeep has quit [Remote host closed the connection]
[15:26:22] -!- BPL has quit [Ping timeout: 250 seconds]
[15:27:14] -!- BPL has joined #pyqt
[15:31:58] -!- BPL has quit [Ping timeout: 268 seconds]
[15:32:53] -!- BPL has joined #pyqt
[15:35:49] -!- mandeep has joined #pyqt
[16:15:45] -!- nitro25 has quit [Remote host closed the connection]
[16:19:56] -!- mandeep has quit [Remote host closed the connection]
[16:20:48] -!- mintograde has joined #pyqt
[16:43:20] -!- Siecje has parted #pyqt
[17:43:22] -!- AbleBacon has quit [Quit: Leaving]
[17:47:23] -!- AbleBacon has joined #pyqt
[18:12:15] -!- AbleBacon has quit [Quit: Leaving]
[19:23:31] -!- BPL has quit [Quit: Leaving]
[19:48:12] -!- mandeep has joined #pyqt
[19:58:34] -!- mandeep has quit [Remote host closed the connection]
[21:08:59] <russw> altendky: there seems to be an issue with .env in that new package:
[21:09:01] <russw> https://bpaste.net
[21:09:07] <russw> unless I misunderstand usage
[21:11:06] <altendky> russw: i forget where I have it searching from. I'll have to check
[21:11:25] <altendky> I usually have my venv inside my project directory so it could be assuming that
[21:30:48] <altendky> We can replace the earlier action item 5) with this
[21:34:41] <russw> :)
[21:34:47] <russw> This reads correctly to me:
[21:34:48] <russw> https://github.com
[21:42:13] <russw> altendky: got it
[21:42:38] <russw> you need to usecwd=True in your dotenv.find_dotenv, like so:
[21:42:41] <russw> env_path = dotenv.find_dotenv(usecwd=True)
[21:42:44] <russw> then it owrks
[21:42:47] <russw> *works
[21:47:13] <altendky> Except in my case I like not having that :] it's more likely to find what I want the way it is. But sure, True is more normal for .env files I think
[21:56:24] <russw> If you *don't* do this, then the .env it find is the one up the chain in the pyqt5_tools dir (from the file making the call). I think.
[22:13:33] -!- mintograde has quit [Ping timeout: 252 seconds]
[22:33:08] -!- Mrokii has quit [Ping timeout: 252 seconds]
[22:37:49] -!- mandeep has joined #pyqt
[22:47:00] -!- Mrokii has joined #pyqt
[22:54:59] <altendky> right. that'll be the one i want it to find. the one in my project dir
[22:55:28] <altendky> not arguing it's proper functionality to have, or what pyqt5-tools should do. just that it does what _i_ want because of how _i_ lay out my envs
[22:56:09] <altendky> which leaves us at one common use case being being able to code the paths to your code in a file that pyqt5-tools can use so you don't have to type it each time.
[22:56:38] <altendky> russw: which means a file (.env or other) in your project. and somehow finding it
[22:57:12] <altendky> which may just require that you be in your project directory (tree somewhere) like a normal .env