Re: [QGIS-Developer] GSoC 2021 QGIS On-the-fly Raster Calculator discussion
Hi Alessandro and thank you for the reply and the advice. I will definitely take it into consideration if I will be able to work on this feature! Francesco Bursi ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Changes in Python versions on QGIS 3.18
Hi Nyall,
>> Until recently [2], such a constraint did not even exist [3] (other than
>> a rather broad "Python 3.X"). Now, you're technically sort of supporting
>> 3.7 to 3.9, although it has not been documented anywhere as far as I
>> know other than in PRs and issues etc. - please correct me if I am wrong.
>
> The discussion happened in public here:
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/197
I am sorry if I did not make myself clear: I am aware that it happened
in public, yes. The documentation of the new constraint can therefore be
found - in public - in a Github issue (in a repository other than the
main QGIS one). Did it ever make its way into the documentation for
plugin developers or ("building QGIS from source" developer
documentation)? In other words, as a (plugin) developer, I currently
have to search and monitor several github repos and at least this
mailing list constantly if I want to know about this kind of stuff.
Actually, I have yet to find the place where updates of critical OSGeo4W
as well as QGIS for Windows installer components are potentially
discussed or announced - in this context, Python 3.9 was also a big
surprise for me.
Besides, in the past, I have basically manually tested my way through a
bunch of relevant permutations of {OS | OS version | QGIS version |
Python version} before I knew what was compatible and what was not.
There is no "support matrix" or similar. This is the kind of work and
responsibility that you're currently leaving to the plugin developers IF
they want to make sure that their stuff actually works across a broad
range of QGIS deployments.
> The rationale is that users on older, slower moving distros can easily
> stick to the stable 3.16 LTR without issues. I.e. older, stable distro
> = older, stable QGIS release.
Makes sense, agreed.
Sebastian
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Multiprocessing QGIS
I am not entirely sure what QGIS' (intended) behavior is in a case like this. From the top of my head, having read the relevant portion of its source code, I'd expect at least a second application window likely followed by non-deterministic behavior (again, depending on the use-case, likely resulting in a crash). Can someone elaborate? I can confirm that the result is non-deterministic even with headless PyQgis programs. For programs relying heavily on multiprocessing the best strategy is to use a `fork-server` process started at the very beginning (before initializing Qgis) managing the pool of child processes, so that each forked process starts in the same state. David, Le 23/03/2021 à 19:22, Sebastian M. Ernst a écrit : Hi João, all, really interesting question. however when i run the plugin a new instance of application is open and give me an error. I assume that you are using `multiprocessing` [1] from Python's standard library. Its default behavior is to use process-based parallelism (as the title in the documentation says). I am assuming that you have not altered its default behavior (e.g. by configuring it to use threads instead). This is why you get at least another "worker" process if you e.g. create a process pool. I have successfully used this method with QGIS before, but always on Linux and OS X. I am just guessing that you are doing this on Windows, right? Depending on the operating system, `multiprocessing` uses different methods to create worker processes. On Linux and OS X, it simply forks [2] the main process. This way, you do not see a second application window popping up. You "simply" get a second, third, fourth, ... process "in the background". On Windows, the `fork` syscall does not exist, neither does something similar [3]. `multiprocessing` therefore starts a complete new process from scratch. If it was pure Python, it would simply start a new Python interpreter process. Because it is QGIS, it opens another instance of QGIS. I am not entirely sure what QGIS' (intended) behavior is in a case like this. From the top of my head, having read the relevant portion of its source code, I'd expect at least a second application window likely followed by non-deterministic behavior (again, depending on the use-case, likely resulting in a crash). Can someone elaborate? Best regards, Sebastian 1: https://docs.python.org/3/library/multiprocessing.html 2: https://en.wikipedia.org/wiki/Fork_(system_call) 3: https://stackoverflow.com/q/985281/1672565 Am 23.03.21 um 13:08 schrieb Joao Folgado: Hi everyone, I had created a plugin for Qgis and I trying to optimize it. So i use in my code the library python that have Queue whit multiprocessing however when i run the plugin a new instance of application is open and give me an error. I had early use this type of multiprocessing before in simple projects in university and it works ok. Can someone help ? I researched in many forums, i see people whit the same question but not with the answer. Thank you very much. Best regards, João Folgado Portugal -- JOÃO FOLGADO ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Changes in Python versions on QGIS 3.18
> > Until recently [2], such a constraint did not even exist [3] (other than > a rather broad "Python 3.X"). Now, you're technically sort of supporting > 3.7 to 3.9, although it has not been documented anywhere as far as I > know other than in PRs and issues etc. - please correct me if I am wrong. The discussion happened in public here: https://github.com/qgis/QGIS-Enhancement-Proposals/issues/197 The rationale is that users on older, slower moving distros can easily stick to the stable 3.16 LTR without issues. I.e. older, stable distro = older, stable QGIS release. Nyall > > Sebastian > > > 1: > https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/FLXUTQB6DY4OAZ43AUUKZ6PCOBDAKBRA/#Y6X4QTXPTIPHCBHIO76I5CAT3C75ZEMH > 2: https://github.com/qgis/QGIS/pull/41778 > 3: https://lists.osgeo.org/pipermail/qgis-developer/2020-March/060495.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Changes in Python versions on QGIS 3.18
Hi Nyall, > we have absolutely no control > over the python versions used by many QGIS users. E.g. as a Fedora > user I've had Python 3.9 for months is not it safe to say that a clear majority of the user base is running Windows where you do have full control? Besides, even in the Linux space, how many "enterprise users" (not developers) are running "bleeding edge distros" like Fedora or Tumbleweed? Leap/SLE is stuck at Python 3.6 (and will be for the foreseeable future [1]), Ubuntu 18.04 LTS is also at 3.6, 20.04 LTS is at 3.8 (hallelujah), CentOS/RHEL 7 is at 3.6 and even CentOS/RHEL 8 appears to be stuck at 3.6. As a consequence, going for 3.7 as a minimum requirement effectively rules out packaging (without intensive patching at least) and (easy) use on many contemporary LTS Linux distros. > Given this I think the responsibility lies with the plugin authors to > ensure they adapt quickly to new Python releases and ensure their > plugin works correctly in all versions of Python supported by the > targeted QGIS versions. Until recently [2], such a constraint did not even exist [3] (other than a rather broad "Python 3.X"). Now, you're technically sort of supporting 3.7 to 3.9, although it has not been documented anywhere as far as I know other than in PRs and issues etc. - please correct me if I am wrong. Sebastian 1: https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/FLXUTQB6DY4OAZ43AUUKZ6PCOBDAKBRA/#Y6X4QTXPTIPHCBHIO76I5CAT3C75ZEMH 2: https://github.com/qgis/QGIS/pull/41778 3: https://lists.osgeo.org/pipermail/qgis-developer/2020-March/060495.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
