Re: [QGIS-Developer] External python package dependency in plugins
Hi,
I added this to my code just 3 days ago :)
import sys
try:
import matplotlib
except:
import subprocess
print('installing matplotlib')
subprocess.call([sys.exec_prefix + '/python', "-m", 'pip',
'install', 'matplotlib'])
import matplotlib
print('installation completed')
I dont know if it is a better or worse solution, I've only tested it on a
Windows machine with the standalone version and the osgeo4w installation.
I tried calling sys.executable first, instead of sys.exec_prefix +
'/python', which resulted in a new qgis window started :)
Axel
On 7 July 2018 at 14:23, Richard Duivenvoorde wrote:
> On 07/07/2018 01:26 PM, shiva reddy wrote:
> > Thanks,
> > In OS X following works:
> > subprocess.call(['pip3','install','pyxform'])
> >
> > Does same works works for Ubuntu/linux also?
> >
> > for windows, I am assuming 'python' refers to python 3 inside QGIS3.
>
> Yep:
>
> import subprocess
> subprocess.call(['pip3','install','pyxform','--user'])
>
> works too.
>
> But as said, not sure if all distro's call the python3 pip: pip3 (and/or
> python3). I still would be afraid to force a specific version of a
> module, as I would be afraid to override some excisting one.
> I do like your solution though, the libs end up in my user site-packages
> dir:
> /home/richard/.local/lib/python3.5/site-packages
>
>
> Ah: http://zetcode.com/lang/python/introspection/
> >>> import sys
> >>> sys.executable
> '/usr/bin/python3'
>
> gives you your actual python exe...
>
> I wonder if you can create an venv from within QGIS in the subprocess way.
> Mmm, this works (from within QGIS):
>
> >>> import sys
> >>> py_exe = sys.executable
> >>> venv_path =
> '/home/richard/.local/share/QGIS/QGIS3/profiles/default/venv'
> >>> subprocess.call([py_exe,'-m','venv', venv_path])
>
> Had to install python3-venv though:
> sudo apt-get install python3-venv
>
> sourcing it does not work with me:
>
> >>> subprocess.call(['source', venv_path+'/bin/activate'])
> FileNotFoundError: [Errno 2] No such file or directory: 'source'
>
> Now somebody with more knowledge of the different python-path/lib-dir's
> should come in, to tell us if this is usable after activating that venv...
>
> Not sure if this would work with the already running python interpreter
> in QGIS...
>
> Idea's?
>
> Regards,
>
> Richard Duivenvoorde
> ___
> 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] External python package dependency in plugins
On 07/07/2018 01:26 PM, shiva reddy wrote: > Thanks, > In OS X following works: > subprocess.call(['pip3','install','pyxform']) > > Does same works works for Ubuntu/linux also? > > for windows, I am assuming 'python' refers to python 3 inside QGIS3. Yep: import subprocess subprocess.call(['pip3','install','pyxform','--user']) works too. But as said, not sure if all distro's call the python3 pip: pip3 (and/or python3). I still would be afraid to force a specific version of a module, as I would be afraid to override some excisting one. I do like your solution though, the libs end up in my user site-packages dir: /home/richard/.local/lib/python3.5/site-packages Ah: http://zetcode.com/lang/python/introspection/ >>> import sys >>> sys.executable '/usr/bin/python3' gives you your actual python exe... I wonder if you can create an venv from within QGIS in the subprocess way. Mmm, this works (from within QGIS): >>> import sys >>> py_exe = sys.executable >>> venv_path = '/home/richard/.local/share/QGIS/QGIS3/profiles/default/venv' >>> subprocess.call([py_exe,'-m','venv', venv_path]) Had to install python3-venv though: sudo apt-get install python3-venv sourcing it does not work with me: >>> subprocess.call(['source', venv_path+'/bin/activate']) FileNotFoundError: [Errno 2] No such file or directory: 'source' Now somebody with more knowledge of the different python-path/lib-dir's should come in, to tell us if this is usable after activating that venv... Not sure if this would work with the already running python interpreter in QGIS... Idea's? Regards, Richard Duivenvoorde ___ 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] External python package dependency in plugins
Thanks, In OS X following works: subprocess.call(['pip3','install','pyxform']) Does same works works for Ubuntu/linux also? for windows, I am assuming 'python' refers to python 3 inside QGIS3. regards, Thanks & Regards Shiva Reddy K. Scientist/Engineer 'SC' Indian Institute of Remote Sensing, Indian Space Research Organisation Department of Space 4-Kalidas Road Dehradun mobile: 8791806093 On Sat, Jul 7, 2018 at 3:15 PM Richard Duivenvoorde wrote: > On 07/07/2018 08:11 AM, shiva reddy wrote: > > Hello, > > I tried to install automatically during my pluign (QRealTime) > > installation by calling: > > > > subprocess.call(['python','-m','install','pyxform','--user']) > > > > It worked many times in windows and it fails sometime. > > It don't work in OS X and I have not tested in ubuntu. > > > > What is the best practice for such situation? > > Hi, I tried your lines here on Debian 9.4/testing/ in a python3 console: > > >>> import subprocess > >>> subprocess.call(['python','-m','install','pyxform','--user']) > /usr/bin/python: No module named install > 1 > >>> subprocess.call(['python','-m','pip','install','pyxform','--user']) > /usr/bin/python: No module named pip > 1 > > Ah, but with Debian we have python and python 3, so I tried: > subprocess.call(['python3','-m','pip','install','pyxform','--user']) > ... > Installing collected packages: argparse, linecache2, traceback2, six, > unittest2, formencode, unicodecsv, xlrd, pyxform > Successfully installed argparse-1.4.0 formencode-1.3.1 linecache2-1.0.0 > pyxform-0.11.3 six-1.11.0 traceback2-1.4.0 unicodecsv-0.14.1 > unittest2-1.1.0 xlrd-1.1.0 > 0 > Works! \o/ > Not sure if (from within python) you can find out what the name of the > python executable is... > > For QGIS2 we earlier recommended to just add the full module into your > plugin package. (if possible, aka python-only module). > > There has also been discussion about using pip for python modules, by > adding the 'pip install line' as a separate metadata.txt line. > In that way we could either let users install it (in their global or > user env), or maybe later do this programatically. > > There are questions/discussions/options: > - how to handle clashing specific versions of the same module between > different plugins > - where to install modules: installation system wide, in one QGIS > virtual environment (venv) or in a venv per plugin > - security questions (mostly a Linux discussion: should a distribution > rely on venv's or only install distribution modules)... etc > > Your idea is (to me) new :-) > If working platform independently and full proof, I think it is an > interesting option! > > Now with QGIS3 we have true separated profiles, we an idea would be to > add a virtual environment PER profile, so all plugins can install > modules in that environment (using your trick?), and in case of a clash > can then create 2 profiles for those plugins/modules. > Not sure though this is feasible for all OS's. I think it will be > easiest on Linux... > > Others? > > Regards, > > Richard Duivenvoorde > ___ 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] External python package dependency in plugins
Hi, thanks for raining this issue and to provide this beautiful solution. Actually having plugin with external python lib dependencies was/is tricky especially for windows system (in my experience) > Now with QGIS3 we have true separated profiles, we an idea would be to > add a virtual environment PER profile, so all plugins can install > modules in that environment (using your trick?), and in case of a clash > can then create 2 profiles for those plugins/modules. > Not sure though this is feasible for all OS's. I think it will be > easiest on Linux... that's also a good idea! Cheers Matteo ___ 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] External python package dependency in plugins
On 07/07/2018 08:11 AM, shiva reddy wrote: > Hello, > I tried to install automatically during my pluign (QRealTime) > installation by calling: > > subprocess.call(['python','-m','install','pyxform','--user']) > > It worked many times in windows and it fails sometime. > It don't work in OS X and I have not tested in ubuntu. > > What is the best practice for such situation? Hi, I tried your lines here on Debian 9.4/testing/ in a python3 console: >>> import subprocess >>> subprocess.call(['python','-m','install','pyxform','--user']) /usr/bin/python: No module named install 1 >>> subprocess.call(['python','-m','pip','install','pyxform','--user']) /usr/bin/python: No module named pip 1 Ah, but with Debian we have python and python 3, so I tried: subprocess.call(['python3','-m','pip','install','pyxform','--user']) ... Installing collected packages: argparse, linecache2, traceback2, six, unittest2, formencode, unicodecsv, xlrd, pyxform Successfully installed argparse-1.4.0 formencode-1.3.1 linecache2-1.0.0 pyxform-0.11.3 six-1.11.0 traceback2-1.4.0 unicodecsv-0.14.1 unittest2-1.1.0 xlrd-1.1.0 0 Works! \o/ Not sure if (from within python) you can find out what the name of the python executable is... For QGIS2 we earlier recommended to just add the full module into your plugin package. (if possible, aka python-only module). There has also been discussion about using pip for python modules, by adding the 'pip install line' as a separate metadata.txt line. In that way we could either let users install it (in their global or user env), or maybe later do this programatically. There are questions/discussions/options: - how to handle clashing specific versions of the same module between different plugins - where to install modules: installation system wide, in one QGIS virtual environment (venv) or in a venv per plugin - security questions (mostly a Linux discussion: should a distribution rely on venv's or only install distribution modules)... etc Your idea is (to me) new :-) If working platform independently and full proof, I think it is an interesting option! Now with QGIS3 we have true separated profiles, we an idea would be to add a virtual environment PER profile, so all plugins can install modules in that environment (using your trick?), and in case of a clash can then create 2 profiles for those plugins/modules. Not sure though this is feasible for all OS's. I think it will be easiest on Linux... Others? Regards, Richard Duivenvoorde ___ 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] Touch screen button: what determins it's availability?
Hi Devs, I've been working on windows machines without touch screens where I had the little 'touch'-button next to the 'pan'-button. I (think) I never had that button on my Linux builds earlier on. BUT... now I have a laptop with a touch screen :-) AND I wanted to try that button/touch-pan (in combi with super full screen :-) ). But I cannot find a cmake prop to enable/disable it. So question: what determines the availability of the touch tool? I'm happy to test/fix stuff if I'm the first one who has this urge... Any hint appreciated. Regards, Richard Duivenvoorde ___ 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] "Early Adopter" release
Hi thanks for your comment Whilst aware of issues with 3.x I have migrated most of my projects to it as it seems to be stable enough for everyday work. I am considering installing the development build onto one of my computers. I also migrated all the shapefiles to geopackage as this appears to be stable enough for production work as well. Since there have been problems lately using shapefiles over a SMB network we hope the Geopackage database works more stably over a network. So far so good - just aware we don't seem to be having much conversation on the redmine site lately :):):) On 07/07/18 19:17, Andreas Neumann wrote: Hi Patrick, QGIS 3.x has major changes under the hood: - Change from qt4 to qt5 - QGIS internal API changes - Change from Python 2 to Python 3 - Completely rewritten: QGIS server, Print composer/layouts, Processing - All Python plugins have to be changed and adopted to the above listed changes With so many changes it is only expected that new issues and problems arise with the introduction of QGIS 3. That's why QGIS 3 is named "early adopter release". On the other hand the devs, and also co-funded by QGIS.ORG, invested a lot of time in fixing issues. And maybe you have noticed that QGIS 3.2 doesn't have this label any more. Version 3.4 is planned as an LT release. 3.4 is scheduled for end of October. See https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule So with 3.4 we expect to be on a stable, at least as good (but most likely much better) than 2.18, which is our previous LT release. If you are cautious and need to rely on stable versions, I recommend rolling out 3.4 after one or two bug fix releases, so maybe at the end of year 2018. However, I personally used version 3.x for quite a long time and I am quite happy with it. Also note, that you can always install and use QGIS 2.x and 3.x in parallel. --- As to your other question: "when do you expect to have made major inroads into the bugs backlog": This is a hard question. The bug queue will never be empty and always contain open issues. On the other hand, there are also issues in the queue that are hard or impossible to reproduce and the bug reporter did not provide enough information to fix the issues. The QGIS.ORG project is investing a five-figure Euro investment (usually 15-40k €) for each release to pay a few core developers to fix the most pressing issues. We do realize that this is not enough, but it is the best we can do with the limited funds. To help improve the situation, we encourage users of QGIS to do either of the following: - help improve the quality of bug reports (really, it can help a lot if bug reporters do an effort to describe the issues well enough to reproduce, including data and a project file - become a sponsor (see https://www.qgis.org/en/site/getinvolved/governance/sponsorship/sponsorship.html#qgis-sponsorship-program and https://www.qgis.org/en/site/about/sponsorship.html#sponsors-and-donors for our list of current sponsors, ideally with an annual renewal commitment - become a one-time donor - establish a support contract with a company, preferable with a company that has core QGIS commiters. See https://www.qgis.org/en/site/forusers/commercial_support.html#core-contributors - with such a contract you can prioritize - hire a developers to specifically fix the issues you have (or if you have the skills, you can fix issues yourself) Or any combination of the above. If a large enough number of users supports us in one or more of the above ways, I am sure we can keep QGIS in a good shape for many years to come. It is the users who decide about the fate of QGIS. If the users stop to support QGIS, QGIS will die. If enough users will support QGIS, it will thrive, as I think it did in the past couple years. Hope this information helps, Greetings from Andreas (QGIS PSC member) Am 07.07.2018 um 06:20 schrieb Patrick Dunford: Can someone please explain to me why Qgis 3.0 banner is named "early adopter release" In other words what stage of development is Qgis 3.0 expected to be at in terms of user experience. As a related question how many bugs do you expect to fix for each release and at what point do you expect to have made major inroads into the bugs backlog. Thanks ___ 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:
Re: [QGIS-Developer] Re-implementing delimited text provider help
Hi Chris, 2018-07-06 22:52 GMT+02:00 Chris Crook : > Hi all > > I am looking for guidance on documentation. > > Can you elaborate on the kind of guidance you need, please? Basically, docs sources are in https://github.com/qgis/QGIS-Documentation repository and clicking the "Fix Me" link at the bottom of any online doc page should bring you to the page source. we have also set some guidelines at https://docs.qgis.org/testing/en/docs/documentation_guidelines/index.html if you want more details but the docs team remains available if you need some particular help. The help for the delimited text provider has largely got lost between > versions 2 and 3. In version 3 is defined in > > QgsHelp::openHelp( QStringLiteral( "managing_data_source/opening_ > data.html#importing-a-delimited-text-file" ) ); > > This links to the QGIS documentation now (after I fixed the url) but that > is very brief. > > Unfortunately it would not be the single broken link but this is a long standing issue I stopped to chase and raise. In version 2 this served as reference documentation for the provider, > including documentation on the url for constructing programmatically as > well as the GUI information. While this is too much information for many > users I would like it to go somewhere > This could certainly be broken up into a number of cross referenced items. > > So I am wondering where this should go now! And what I need to do to get > it there. > > I gave a quick look to the 2.18 context help and indeed looks like there's a lot of valuable information we can move to the online docs. From what I see I think changes could go to: - https://docs.qgis.org/testing/en/docs/user_manual/managing_data_source/opening_data.html#importing-a-delimited-text-file - https://docs.qgis.org/testing/en/docs/user_manual/managing_data_source/supported_data.html#delimited-text-files - and somewhere in the PyQGIS cookbook but I don't know the logic of structuring this document and it does not really get updates for 3, yet. Maybe somewhere around https://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/loadlayer.html ? Hope that helps, otherwise feel free to ask. And thanks for offering your help. Regards, Harrissou > Thanks > Chris > > > > This message contains information, which may be in confidence and may be > subject to legal privilege. If you are not the intended recipient, you must > not peruse, use, disseminate, distribute or copy this message. If you have > received this message in error, please notify us immediately (Phone 0800 > 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ > accepts no responsibility for changes to this email, or for any > attachments, after its transmission from LINZ. Thank You. > ___ > 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] "Early Adopter" release
Hi again, Patrick, Some other thoughts: I recently visited the SWISS PGDAY (organized by Swiss PostgreSQL user group). The very interesting keynote was by Bruce Momjian - a long time core contributor of PostgreSQL. The title of the keynote was "Will PostgreSQL live forever?" Some answers to this hard to answer question are: - Forever, is a long time ;-) - It is up to the users and developers to decide whether PostgreSQL stays relevant or will be made irrelevant by other - there is no management that decides it. It is the users who decide it. - the good news is: as Open Source organizations we are not at the mercy of financial investors or have to react to quarterly statements. This makes us, much much more likely to live longer than commercial alternatives. - commercial companies: if the owners/investors got enough money out of the product they may loose interest or decide that a new feature a customer demands costs only money and not bring enough profit. So, it is the owners and the management of the product who decide what gets into the product, whereas with OpenSource the users and developers have more power over such decisions. - the other good news is: neither PostgreSQL nor QGIS can be bought by another company (only the companies of the core contributors can be bought). Luckily, in neither project a single company has too much power over development of the projects. If one company ceases or is bought and shut-down, there are plenty of other devs and companies who can take over - if the users want that. - in worst case scenarios, projects can still be forked Greetings, Andreas Am 07.07.2018 um 06:20 schrieb Patrick Dunford: Can someone please explain to me why Qgis 3.0 banner is named "early adopter release" In other words what stage of development is Qgis 3.0 expected to be at in terms of user experience. As a related question how many bugs do you expect to fix for each release and at what point do you expect to have made major inroads into the bugs backlog. Thanks ___ 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] "Early Adopter" release
Hi Patrick, QGIS 3.x has major changes under the hood: - Change from qt4 to qt5 - QGIS internal API changes - Change from Python 2 to Python 3 - Completely rewritten: QGIS server, Print composer/layouts, Processing - All Python plugins have to be changed and adopted to the above listed changes With so many changes it is only expected that new issues and problems arise with the introduction of QGIS 3. That's why QGIS 3 is named "early adopter release". On the other hand the devs, and also co-funded by QGIS.ORG, invested a lot of time in fixing issues. And maybe you have noticed that QGIS 3.2 doesn't have this label any more. Version 3.4 is planned as an LT release. 3.4 is scheduled for end of October. See https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule So with 3.4 we expect to be on a stable, at least as good (but most likely much better) than 2.18, which is our previous LT release. If you are cautious and need to rely on stable versions, I recommend rolling out 3.4 after one or two bug fix releases, so maybe at the end of year 2018. However, I personally used version 3.x for quite a long time and I am quite happy with it. Also note, that you can always install and use QGIS 2.x and 3.x in parallel. --- As to your other question: "when do you expect to have made major inroads into the bugs backlog": This is a hard question. The bug queue will never be empty and always contain open issues. On the other hand, there are also issues in the queue that are hard or impossible to reproduce and the bug reporter did not provide enough information to fix the issues. The QGIS.ORG project is investing a five-figure Euro investment (usually 15-40k €) for each release to pay a few core developers to fix the most pressing issues. We do realize that this is not enough, but it is the best we can do with the limited funds. To help improve the situation, we encourage users of QGIS to do either of the following: - help improve the quality of bug reports (really, it can help a lot if bug reporters do an effort to describe the issues well enough to reproduce, including data and a project file - become a sponsor (see https://www.qgis.org/en/site/getinvolved/governance/sponsorship/sponsorship.html#qgis-sponsorship-program and https://www.qgis.org/en/site/about/sponsorship.html#sponsors-and-donors for our list of current sponsors, ideally with an annual renewal commitment - become a one-time donor - establish a support contract with a company, preferable with a company that has core QGIS commiters. See https://www.qgis.org/en/site/forusers/commercial_support.html#core-contributors - with such a contract you can prioritize - hire a developers to specifically fix the issues you have (or if you have the skills, you can fix issues yourself) Or any combination of the above. If a large enough number of users supports us in one or more of the above ways, I am sure we can keep QGIS in a good shape for many years to come. It is the users who decide about the fate of QGIS. If the users stop to support QGIS, QGIS will die. If enough users will support QGIS, it will thrive, as I think it did in the past couple years. Hope this information helps, Greetings from Andreas (QGIS PSC member) Am 07.07.2018 um 06:20 schrieb Patrick Dunford: Can someone please explain to me why Qgis 3.0 banner is named "early adopter release" In other words what stage of development is Qgis 3.0 expected to be at in terms of user experience. As a related question how many bugs do you expect to fix for each release and at what point do you expect to have made major inroads into the bugs backlog. Thanks ___ 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] External python package dependency in plugins
minor correction: subprocess.call(['python','-m','pip','install','pyxform','--user']) Thanks & Regards Shiva Reddy K. Scientist/Engineer 'SC' Indian Institute of Remote Sensing, Indian Space Research Organisation Department of Space 4-Kalidas Road Dehradun mobile: 8791806093 On Sat, Jul 7, 2018 at 11:40 AM shiva reddy wrote: > Hello, > I tried to install automatically during my pluign (QRealTime) installation > by calling: > > subprocess.call(['python','-m','install','pyxform','--user']) > > It worked many times in windows and it fails sometime. > It don't work in OS X and I have not tested in ubuntu. > > What is the best practice for such situation? > > > Thanks & Regards > Shiva Reddy K. > Scientist/Engineer 'SD' > Indian Institute of Remote Sensing, > Indian Space Research Organisation > Department of Space > 4-Kalidas Road > Dehradun > mobile: 7017035414 > ___ 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] External python package dependency in plugins
Hello, I tried to install automatically during my pluign (QRealTime) installation by calling: subprocess.call(['python','-m','install','pyxform','--user']) It worked many times in windows and it fails sometime. It don't work in OS X and I have not tested in ubuntu. What is the best practice for such situation? Thanks & Regards Shiva Reddy K. Scientist/Engineer 'SD' Indian Institute of Remote Sensing, Indian Space Research Organisation Department of Space 4-Kalidas Road Dehradun mobile: 7017035414 ___ 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
