Re: [QGIS-Developer] QGIS plugin depends on pypi package

[Julien Moura via QGIS-Developer]

Hello John,


It's a recurring issue/question since QGIS does not support pip 
dependencies and that PyQGIS plugins are not following the official 
Python packaging standards from PEPs and related formats (typically 
metadata.txt instead of setup.cfg, pyproject.toml). You will find some 
unsuccessful QEPs about this. For example: 
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/202.



Shortly, here come 3 workarounds:

 * basic: run pip install in a rough subcommand. Not so elegant but
   still efficient.
 * re-wheeling: implement a minimalist (or complete) 3rd party packages
   managers, miming pip through QgsNetwork tooling. Best example I know
   until today: ENMap-Box plugin (see attached screenshot or try it
   yourself).
 * YAML addicts: run your pip install during your plugin's packaging
   job in CI and include external dependencies in a subfolder before
   deploying it to your favorite plugins repository. Then, manage
   install loading from your plugin with try/except ImportError and
   'site' module. This is the way I prefer and use for years now. Main
   downside: for dependencies requiring a specific compilation on an
   operating system, you need to include various outputs. See Roof
   Classify  (GitHub
   Workflow), Thyrsis 
   (GitLab CI), QSoccer 
   (GitLab CI), QDuckDB 
   (GitLab CI)... If you're interested, let me know. It could motivate
   me to write a tutorial detailing this method.
 * bravehearts: working on packaging your dependencies into osgeo4w;
   but they probably won't be included in default QGIS packages (.msi)

Just a quick advice: if you do some pip install within your plugin, 
during the packaging or during the run, make it under a custom folder 
related only to your plugin and use site to load extra dependencies in 
the QGIS Python environment to avoid issues.



Good luck!

Regards

Julien


Le 19/01/2024 à 19:16, John Lindsay via QGIS-Developer a écrit :


Agreed, when I 'print(sys.executable)' from within the QGIS Python 
Console (on my MacBook Pro), I see:



/Applications/QGIS.app/Contents/MacOS/QGIS


But from my system terminal, I see:

/Library/Frameworks/Python.framework/Versions/3.11/bin/python3


So QGIS, at least on a Mac, does seem to have it's own version of 
Python installed. And there is not clear way, again on a Mac at least, 
to pip install to the QGIS Python such that a plugin will be able to 
see a package. Now, this said, on my Linux machine, installing my 
Whitebox Workflows plugin did not run into an error at all and so I'm 
left wondering if this is perhaps, as Greg suggested, a particular 
binary distribution issue related to QGIS on MacOS. Could be.


Regards,

John

Prof. John Lindsay

Dept. of Geography, Environment & Geomatics,

The University of Guelph,

Room 122, Hutt Building,

E-mail: jlind...@uoguelph.ca

Phone: (519) 824-4120 ext. 56074

Web: https://geg.uoguelph.ca/faculty/lindsay-john

Research page: https://jblindsay.github.io/ghrg/index.html

WhiteboxTools GIS project: https://www.whiteboxgeo.com/

Twitter: https://twitter.com/whiteboxgeo


*From:* David Strip 
*Sent:* Friday, January 19, 2024 1:10 PM
*To:* Greg Troxel ; John Lindsay 
*Cc:* John Lindsay via QGIS-Developer 
*Subject:* Re: [QGIS-Developer] QGIS plugin depends on pypi package
CAUTION: This email originated from outside of the University of 
Guelph. Do not click links or open attachments unless you recognize 
the sender and know the content is safe. If in doubt, forward 
suspicious emails to ith...@uoguelph.ca.


On 1/19/2024 10:59 AM, Greg Troxel via QGIS-Developer wrote:

When you say "qgis seems to use its own version", I wonder if that is in
the context of particular binary distribution.  And if there really is a
full extra copy of libs, or if it's about a per-user site-packages
directory.
The OS4Geo binary distribution contains a Python39 directory which is 
a full python installation including python.exe, a Lib directory which 
in turn contains a site-packages directory. As least in my case, this 
is installed system-wide, not per-user


___
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-developerBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List 

Re: [QGIS-Developer] QGIS Full Stack Web Developer Report

[Julien Moura via QGIS-Developer]

Hello,

Thanks again for the technical work and improving the workflow.

+1 for the lazy consensus on non breaking changes.

Regarding the license topic:

+1 for the metadata field with a spdx license. But take care, it's not 
so easy to a have an exhaustive list. Maybe we should move to the PyPi 
classifiers since plugins are Python packages and there is already a 
work on maintaining a metadata ecosystem, including tooling to check it 
(pip install packaging).


Are we okay with the step back to only a non-blocking warning?

Regards

On 27/11/2023 10:50, Lova Andriarimalala via QGIS-Developer wrote:


Hello everyone,

Thank you all. It's truly an honorto work on this project.

I will begin by utilizing QEP to create a QEP that summarizes this 
discussion and going forward with the suggestion to make the license 
file recommended for now.


I have reviewed the tickets in the backlog and will evaluate their 
size. If I come across anything that I don't understand, I will add 
comments to seek clarification.


Best regards,

Lova

—**

Image

*Lova Andriarimalala***

*QGIS Full Stack Developer***

Visit http://kartoza.com  to find out about open 
source:


* Desktop GIS programming services

* Geospatial web development

* GIS Training

* Consulting Services

Office: +261(0)34 09 524 73 

*From: *QGIS-Developer  on 
behalf of Matthias Kuhn via QGIS-Developer 


*Date: *Monday, 27 November 2023 at 12:24 PM
*To: *Tim Sutton 
*Cc: *qgis-developer@lists.osgeo.org 
*Subject: *Re: [QGIS-Developer] QGIS Full Stack Web Developer Report

Hi Tim,

For the workflow, that sounds great, thanks a lot!

I agree only breaking changes should go "the long way" and for simple 
fixes and improvements we should just get them done with low overhead.


Going forward with a small QEP for the license sounds very good.

Regarding the metadata, I would suggest we use the ids from 
https://spdx.org/licenses/.


So for the usual QGIS plugin case, that would be

  license=GPL-2.0-or-later

On another note, I just added a couple of tickets to the backlog, I am 
not able to estimate the size of them, so if they are too complicated, 
just don't prioritize them.


Thank you and best regards

Matthias

On Mon, Nov 27, 2023 at 10:15 AM Tim Sutton  wrote:

Hi all

On Mon, Nov 27, 2023 at 1:32 AM Nyall Dawson
 wrote:


On Mon, 27 Nov 2023 at 00:19, Tim Sutton via QGIS-Developer
 wrote:
>
> @Matthias Kuhn and @Julien Moura I fixed the permissions,
the board for Lova is public now. Please feel free to add
items to the backlog and mark them as priority as needed.  I
also asked Lova to try to work through all the old issues and
fix / close them as appropriate so we can try to get the
number of tickets down to a small number.

Tim/Lova, thanks for your outstanding efforts and
commitment here!

It's really exciting to see all the love and attention that
the web and plugin infrastructure is getting as a result! 😍

Thanks so much Nyall and all credit goes to Lova who is doing
fantastic work! What I suggest is that moving forward, Lova uses
QEP's too propose and discuss breaking / major workflow changes on
the plugins site. In that QEP he can address:

* what the change is (link back to ticket in QGIS-Django for example)

* what the impact will be

* proposed roll out time line

etc.

And we can discuss and agree these changes there before he goes
ahead with it. For smaller changes, I suggest he 'just get on with
it' - his scrum board is public and you are all welcome to help
prioritise his work.

For the current issue under discussion (license requirements for
plugins), I have asked Lova to make a QEP and synthesize the
discussion there, mainly so he can have a practice run at going
through the QEP process, although I will add my 2c that I like
Matthias' simple solution to the problem (adding license as a line
to the metadata.txt). If I understand you right Matthias, our
metadata would then look like this?:

-

[general]
name=QGIS Animation Workbench
description=A plugin to let you build animations in QGIS
about=QGIS Animation Bench exists because we wanted to use all the
awesome cartography features in QGIS and make cool, animated maps!
QGIS already includes the Temporal Manager which allows you to
produce animations for time-based data. But what if you want to
make animations where you travel around the map, zooming in and
out, and perhaps making features on the map wiggle and jiggle as
the animation progresses? That is what the animation workbench
tries to solve...
version=1.1
qgisMinimumVersion=3.0
author=Tim Sutton
email=t...@kartoza.com
repository=https://github.com/timlinux/QGISAnimationPlugin
license=GPLv2

-

Re: [QGIS-Developer] QGIS Full Stack Web Developer Report

[Julien Moura via QGIS-Developer]

ow. If so, I will also fix
the new plugin upload.

Kind regards.

—

Image

*Lova Andriarimalala*

*QGIS Full Stack Developer*

Visit http://kartoza.com <http://kartoza.com/> to find out
about open source:

* Desktop GIS programming services

* Geospatial web development

* GIS Training

* Consulting Services

Office: +261(0)34 09 524 73 

*From: *QGIS-Developer

<mailto:qgis-developer-boun...@lists.osgeo.org> on behalf of
Julien Moura via QGIS-Developer

<mailto:qgis-developer@lists.osgeo.org>
*Date: *Friday, 24 November 2023 at 10:30 AM
*To: *qgis-developer@lists.osgeo.org

<mailto:qgis-developer@lists.osgeo.org>
*Subject: *Re: [QGIS-Developer] QGIS Full Stack Web Developer
Report

Hello Lova,

I cross post my comment to this issue
<https://github.com/qgis/QGIS-Django/issues/38#issuecomment-1824010198>
related to the PR mentioned below as "Make LICENSE file as
required in plugin package
<https://github.com/qgis/QGIS-Django/pull/309>", because I did
not have any answer there but saw that some changes still have
been applied without any comment.

While trying to publish or update a plugin, we faced the new
error message related to the deployment of this PR
<https://github.com/qgis/QGIS-Django/pull/309>:

> Fault string: 

See downstream issue on qgis-plugin-ci project (disclaimer:
I'm one of the mainteners but speaking on my own here):
https://github.com/opengisch/qgis-plugin-ci/issues/255

I think this kind of change, which breaks the
plugins'publication flow, should be discussed before to be
implemented (an issue from 1 person seems to be too light to
decide without any discussion), announced to the community, a
warning campaign should be run and a transitional phase should
be implemented (warning for 6 months, then error). This has a
direct impact on hundreds (thousands?) of plugin developers on
a community project with several million end users.

I understand that this process may seem too cumbersome, and
that since the QGIS Django project hasn't been so dynamic for
a few years, it's nice to see it get a new lease of life, even
if it means merging and deploying on an ongoing basis.

As for the underlying principle, I'm generally in favor of
strengthening the control mechanisms (automatic or otherwise)
for extensions on the official repository, but I think it's
really important to do this gradually, or at least to avoid
unilateral change "descended from the skies of the developers".

Concerning the idea of integrating the license in the plugin
package, I'm not really convinced of the interest since most
plugins are contaminated by the GPL2+ of QGIS <-- Qt and the
license is never displayed to the end user. But why not. After
all, it's always a good practice to include licence and spread
the word about (re)usage rules.

Reverting sounds maybe too rought so I suggest modyfing the
behavior to lower the level and make it a simple warning and
in the meanwhile starting a communication and preventive work
upstream:

 1. update documentation:

https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/plugins/plugins.html
 2. communicate on the QGIS Dev list **before** the
implementation to discuss the rationale
 3. integrate a warning mechanism
 4. manage the QGIS versions concerned (only applicable to new
QGIS released versions after this being merged)

A last question: did you have some pre-production environment
where to deploy new changes in order to evaluate them before
publishing widely? Or some versioning logic, milestone
workflow where PRs are grouped before being deployed?

Regards,
Julien

On 17/11/2023 13:59, Lova Andriarimalala via QGIS-Developer wrote:

Hello everyone,

Please find below the report summarizing the progress on
the feed and plugins websitedevelopment for this week.

*PRs open:*

1.Add support for renaming plugin name
<https://github.com/qgis/QGIS-Django/pull/302>

2.Add command to fix none in search results
<https://github.com/qgis/QGIS-Django/pull/304>

3.Show more records, records items per page
<https://github.com/qgis/QGIS-Django/pull/306>

4.Specify tag page title and other plugin page

Re: [QGIS-Developer] QGIS Full Stack Web Developer Report

[Julien Moura via QGIS-Developer]

Thanks for your quick reply here Lova,

I've no special legibility that my opinion would be greater than yours, 
so I can't tell if it has to be reverted or not. That's why I ask for 
discussion before deploying some breaking change, without any warning or 
information. After having looked to others PR, I would like to see more 
description about what a PR does exactly, especially when it breaks 
something.


In this case, even after the last PR, this is a breaking and 
undocumented change. For now, a plugin developer has no way to see that 
a LICENSE file is now required in its plugin's zip. An error message in 
a log is not a suitable information, even it's well formulated and 
clear, especially in the era of automated CI/CD deployments.


Regards,
Julien

On 24/11/2023 08:35, Lova Andriarimalala wrote:


Dear Julien,

Many thanks for your feedback.

In the newPR, the license file is only required for new plugins. For 
existing plugin updates, it generates just a warning (but doesn't 
fail) when the license file is missing.


However, I'm not sure if we should also just generate a warning for 
new plugin uploads for now. If so, I will also fix the new plugin upload.


Kind regards.

—**

Image

*Lova Andriarimalala***

*QGIS Full Stack Developer***

Visit http://kartoza.com <http://kartoza.com/> to find out about open 
source:


* Desktop GIS programming services

* Geospatial web development

* GIS Training

* Consulting Services

Office: +261(0)34 09 524 73 

*From: *QGIS-Developer  on 
behalf of Julien Moura via QGIS-Developer 

*Date: *Friday, 24 November 2023 at 10:30 AM
*To: *qgis-developer@lists.osgeo.org 
*Subject: *Re: [QGIS-Developer] QGIS Full Stack Web Developer Report

Hello Lova,

I cross post my comment to this issue 
<https://github.com/qgis/QGIS-Django/issues/38#issuecomment-1824010198> 
related to the PR mentioned below as "Make LICENSE file as required in 
plugin package <https://github.com/qgis/QGIS-Django/pull/309>", 
because I did not have any answer there but saw that some changes 
still have been applied without any comment.


While trying to publish or update a plugin, we faced the new error 
message related to the deployment of this PR 
<https://github.com/qgis/QGIS-Django/pull/309>:


> Fault string: plugin compressed archive. Cannot find LICENSE in plugin package.'>


See downstream issue on qgis-plugin-ci project (disclaimer: I'm one of 
the mainteners but speaking on my own here): 
https://github.com/opengisch/qgis-plugin-ci/issues/255


I think this kind of change, which breaks the plugins'publication 
flow, should be discussed before to be implemented (an issue from 1 
person seems to be too light to decide without any discussion), 
announced to the community, a warning campaign should be run and a 
transitional phase should be implemented (warning for 6 months, then 
error). This has a direct impact on hundreds (thousands?) of plugin 
developers on a community project with several million end users.


I understand that this process may seem too cumbersome, and that since 
the QGIS Django project hasn't been so dynamic for a few years, it's 
nice to see it get a new lease of life, even if it means merging and 
deploying on an ongoing basis.


As for the underlying principle, I'm generally in favor of 
strengthening the control mechanisms (automatic or otherwise) for 
extensions on the official repository, but I think it's really 
important to do this gradually, or at least to avoid unilateral change 
"descended from the skies of the developers".


Concerning the idea of integrating the license in the plugin package, 
I'm not really convinced of the interest since most plugins are 
contaminated by the GPL2+ of QGIS <-- Qt and the license is never 
displayed to the end user. But why not. After all, it's always a good 
practice to include licence and spread the word about (re)usage rules.


Reverting sounds maybe too rought so I suggest modyfing the behavior 
to lower the level and make it a simple warning and in the meanwhile 
starting a communication and preventive work upstream:


 1. update documentation:

https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/plugins/plugins.html
 2. communicate on the QGIS Dev list **before** the implementation to
discuss the rationale
 3. integrate a warning mechanism
 4. manage the QGIS versions concerned (only applicable to new QGIS
released versions after this being merged)

A last question: did you have some pre-production environment where to 
deploy new changes in order to evaluate them before publishing widely? 
Or some versioning logic, milestone workflow where PRs are grouped 
before being deployed?


Regards,
Julien

On 17/11/2023 13:59, Lova Andriarimalala via QGIS-Developer wrote:

Hello everyone,

Please find below the report summarizing the progress on the feed
 

Re: [QGIS-Developer] QGIS Full Stack Web Developer Report

[Julien Moura via QGIS-Developer]

Hello Lova,

I cross post my comment to this issue 
 
related to the PR mentioned below as "Make LICENSE file as required in 
plugin package ", because 
I did not have any answer there but saw that some changes still have 
been applied without any comment.


While trying to publish or update a plugin, we faced the new error 
message related to the deployment of this PR 
:


> Fault string: plugin compressed archive. Cannot find LICENSE in plugin package.'>


See downstream issue on qgis-plugin-ci project (disclaimer: I'm one of 
the mainteners but speaking on my own here): 
https://github.com/opengisch/qgis-plugin-ci/issues/255


I think this kind of change, which breaks the plugins'publication flow, 
should be discussed before to be implemented (an issue from 1 person 
seems to be too light to decide without any discussion), announced to 
the community, a warning campaign should be run and a transitional phase 
should be implemented (warning for 6 months, then error). This has a 
direct impact on hundreds (thousands?) of plugin developers on a 
community project with several million end users.


I understand that this process may seem too cumbersome, and that since 
the QGIS Django project hasn't been so dynamic for a few years, it's 
nice to see it get a new lease of life, even if it means merging and 
deploying on an ongoing basis.


As for the underlying principle, I'm generally in favor of strengthening 
the control mechanisms (automatic or otherwise) for extensions on the 
official repository, but I think it's really important to do this 
gradually, or at least to avoid unilateral change "descended from the 
skies of the developers".


Concerning the idea of integrating the license in the plugin package, 
I'm not really convinced of the interest since most plugins are 
contaminated by the GPL2+ of QGIS <-- Qt and the license is never 
displayed to the end user. But why not. After all, it's always a good 
practice to include licence and spread the word about (re)usage rules.


Reverting sounds maybe too rought so I suggest modyfing the behavior to 
lower the level and make it a simple warning and in the meanwhile 
starting a communication and preventive work upstream:


1. update documentation:
   
https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/plugins/plugins.html
2. communicate on the QGIS Dev list **before** the implementation to
   discuss the rationale
3. integrate a warning mechanism
4. manage the QGIS versions concerned (only applicable to new QGIS
   released versions after this being merged)

A last question: did you have some pre-production environment where to 
deploy new changes in order to evaluate them before publishing widely? 
Or some versioning logic, milestone workflow where PRs are grouped 
before being deployed?


Regards,
Julien

On 17/11/2023 13:59, Lova Andriarimalala via QGIS-Developer wrote:


Hello everyone,

Please find below the report summarizing the progress on the feed and 
plugins websitedevelopment for this week.


*PRs open:*

  * Add support for renaming plugin name

  * Add command to fix none in search results

  * Show more records, records items per page

  * Specify tag page title and other plugin page title

  * Make LICENSE file as required in plugin package


*PR merged:*

  * Update dockerfile and requirements for production

  * Update requirements according to production

  * Add geoip2 in production, setting up log

  * Use contry code when testing daily_visit.country


*Still working on:*

  * Fresh plugin includes obsolete stuff


Changes to the QGIS Feed website are now deployed and available at 
https://feed.qgis.org.


Have a great weekend,

Lova

—**

Image

*Lova Andriarimalala***

*QGIS Full Stack Developer***

Visit http://kartoza.com  to find out about open 
source:


* Desktop GIS programming services

* Geospatial web development

* GIS Training

* Consulting Services

Office: +261(0)34 09 524 73 

*From: *Lova Andriarimalala 
*Date: *Friday, 10 November 2023 at 5:32 PM
*To: *qgis-developer@lists.osgeo.org 
*Subject: *Re: QGIS Full Stack Web Developer Report

Hello everyone,

Please find below the report summarizing the progress on the feed and 
plugins websitedevelopment for this week.


*PRs open:*

  * Add support for renaming plugin name

Re: [QGIS-Developer] QGIS-CH mini workshop on QGIS installations, file locations, profiles, shared resources, etc.

[Julien Moura via QGIS-Developer]

Hi Andreas,

It's good to know that the Swiss QGIS user group organizes common times 
for sharing experience and practice. It seems to be a great collective 
dynamic!


About the next mini-workshop on QGIS installations and deployment, this 
is a topic we're trying to be quite active on at Oslandia by working on 
custom packaging for the OSGeo4W installer, un/install workflow 
automations (PowerShell) and especially on deployment strategies for 
QGIS profiles and customizations. We're relying on QDT (QGIS Deployment 
Toolbelt) 
, a tool 
we're developing on a community basis according to customer needs. It is 
based on the same synchronization mechanism as the Resource Sharing 
plugin  
(pseudo-git), a deployment scenario (inspired from ansible) and on an 
abstraction of the QGIS profile via a 'profile.json' file.


In addition, there's the Profile Manager plugin, which we recommend 
using and to which we plan to contribute to make it capable of exporting 
to the QDT formalism.


Regards,

Julien

Le 10/10/2023 à 10:04, Andreas Neumann via QGIS-Developer a écrit :

Dear QGIS developers and contributors,

The Swiss QGIS user group organizes mini workshops and demos for its 
members. These meetings are online on Google Meet (guests from other 
countries are welcome). Several of the devs and contributors on this 
list had instructed such workshops in the past.


One idea that came up is to organize a mini workshop around QGIS 
installations (what different options are around, what are the 
differences), explanation of the file systems (where are all the 
binaries and config files), profiles, shared resources, what is 
centralized and what is configure per user, etc.


Thank you for your replies in case you could volunteer to help 
instruct such a workshop,

Andreas

--
Andreas Neumann
QGIS.ORG  board member (treasurer)

___
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-developerBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
ORG:Oslandia;
N:Moura;Julien;;;
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:6f70c391-976b-453a-af59-4f7089ddaafc
END:VCARD
___
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] QGIS Documentation Writer - Report

[Julien Moura via QGIS-Developer]

Hello,

Thanks for your work, it's really appreciated and useful for the project.

On 15/09/2023 18:37, DelazJ via QGIS-Developer wrote:

Hi,

Thanks Selma for the report and your work.

Le ven. 15 sept. 2023 à 17:42, Selma Vidimlic via QGIS-Developer 
 a écrit :


Hello all,

[snif]
Pull request that needs a feedback:

  * Add GIS File


For precision, the PR needs feedback from a developer or user.

Greetings,
Harrissou

Issue that I've been working on but PR is still not created:

  * Fill expression functions docs with visual examples


Have a nice weekend,
Selma.


-- 
Selma Vidimlic Husic

QGIS Documentation Writer
Visit http://kartoza.comto find out about open source:
* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services
Phone: +387 61 933 651
___
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-developerBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] HTTP POST multipart/form-data using PyQGIS

[Julien Moura via QGIS-Developer]

Hello,

I'm working on a QGIS plugin to upload images to an instance (STAC) via 
a REST API.


I've found some examples 
(https://lists.osgeo.org/pipermail/qgis-developer/2022-January/064437.html) 
but they don't use the PyQGIS API, whereas I need support for 
authentication configurations and proxy settings.


Is this currently possible?


Regards,
julien
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] Structured list of QGIS versions with flags?

[Julien Moura via QGIS-Developer]

Hi Régis,

So, the answer is no but good news: the information is publicly 
available! Thanks for your answer and point me to these files :). I was 
looking to the schedule.ics but it's incomplete (no flags).


I'm going to work with it (github tags) and see if I can automatically 
generate a JSON file.


Regards

Le 26/05/2023 à 12:37, Régis Haubourg a écrit :

Hi Julien,
not sure if this is the real source of truth, but the git history of 
this file seems pretty structured : 
https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py


OIherwise git tags of main repo may do the trick.
Ciao


Le ven. 26 mai 2023 à 10:58, Julien Moura via QGIS-Developer 
 a écrit :


Hello QGIS dev community,

Is there a publicly accessible structured file (JSON, CSV, etc.) that
lists QGIS versions and their status: deprecated, development,
LTR, etc.?

Regards,
Julien
___
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
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] Structured list of QGIS versions with flags?

[Julien Moura via QGIS-Developer]

Hello QGIS dev community,

Is there a publicly accessible structured file (JSON, CSV, etc.) that 
lists QGIS versions and their status: deprecated, development, LTR, etc.?


Regards,
Julien
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] PyQGIS icons cheatsheet

[Julien Moura via QGIS-Developer]

Hi there,

Following this work, Benjamin Jakimow (developer of the ENMap-Box) and I 
worked on a plugin that introduces a resource browser right into QGIS:


 * plugin page <https://plugins.qgis.org/plugins/pyqgis_resource_browser/>
 * source code <https://github.com/Guts/qgis-plugin-resource-browser>

The logic is mainly an extraction of the resource browser that already 
existed in dev tools of ENMap-Box 
<https://www.enmap.org/data_tools/enmapbox/> (full credit to Benjamin) 
dropped into a boilerplate generated from the QGIS Plugin Templater 
<https://oslandia.gitlab.io/qgis/template-qgis-plugin/> (presented in 
Firenze 
<https://jmoura.pages.oslandia.io/presentations/2022/foss4g_qgis_plugin_development_sota.html>).


Hope it can helps, if so enjoy!

Happy contributor/user meeting!

Regards,
Julien

Le 17/03/2023 à 21:34, Julien Moura via QGIS-Developer a écrit :


Of course, why not?
But I'm not sure it's worth it, as there's not much original text, as 
it's mostly technical notes.


Or are you talking about blog posts?

Kind regards,
Julien

Le 17/03/2023 à 11:29, Luca Manganelli a écrit :

Fantastic! It is possible to make a translated version?






Comune di Trento

via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221

tel. +39 0461.884111 | www.comune.trento.it <http://www.comune.trento.it>



___
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-developerBEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] PyQGIS icons cheatsheet

[Julien Moura via QGIS-Developer]

Of course, why not?
But I'm not sure it's worth it, as there's not much original text, as 
it's mostly technical notes.


Or are you talking about blog posts?

Kind regards,
Julien

Le 17/03/2023 à 11:29, Luca Manganelli a écrit :

Fantastic! It is possible to make a translated version?






Comune di Trento

via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221

tel. +39 0461.884111 | www.comune.trento.it 
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] PyQGIS icons cheatsheet

[Julien Moura via QGIS-Developer]

Hello,

Just to publicize a side-project that I've been working on recently: 
https://pyqgis-icons-cheatsheet.geotribu.fr/.


A website to list and preview icons shipped with QGIS. The idea and the 
first realisation are already two years old (see this blog post 
 
and this one 
) 
but it was entirely manual and therefore not up to date at all.


Recently, I worked on complete automation using GitHub Workflow: 
scheduled to run monthly, it parses the QGIS resources file 
 and rebuild 
and publish the website.


Hope it can help some plugins developers!

Best regards,
Julien
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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] Offering QGIS installers through Windows store

[Julien Moura via QGIS-Developer]

Hello,

I'm working on the packaging purpose at Oslandia.

Because we are committed to pushing QGIS in the most industrial 
information systems, at Oslandia we have been very interested in QGIS 
deployment for a few years now.


We have reused and actively contributed to many projects: OSGeo4W v1 
mirror, NSIS and PowerShell recipes, presentations at FOSS4Gs (or at 
QGIS conferences), etc.


Since this year, we are making efforts to de-correlate software 
deployment and end-user configurations (profiles): the QGIS Deployment 
Toolbelt (https://guts.github.io/qgis-deployment-cli/) has been created 
with this goal. It is still a young project and also it is one project 
among many others.


We are obviously very interested in this project of packaging QGIS on 
Windows Store, a topic that we already discussed internally last year 
and that I discussed namely with Régis Haubourg in Florence. We 
obviously have some question marks and discussion points to make sure 
that all the process is in line with community and open-source 
governance. Still, it will be quite a challenge and we think it is a 
good direction to follow.


As noted by others, this seems a huge undertaking though, and 
uncertainty paves the road and make this goal a distant future.


We could start with gathering and referencing all resources dedicated to 
packaging, which would sum up as a website ( packaging.qgis.org ?) with 
all documentation regarding OSGeo4W recipes ( beyond the aging OSGeo 
trac ), and other packaging methods, like customized .deb packaging.


The goal is to structure and promote knowledge on this topic to attract 
packager in addition to developers.


And then we would also create packaging process documentation for 
Windows Store.


Regards,
Julien M

Le 23/11/2022 à 10:41, Even Rouault via QGIS-Developer a écrit :


- There is a requirement for every library in the package to be "UWP 
compatible".
  At that time, libpq (postgresql) didn't have that, so I stopped. 
It's hard to say how many other packages will also need special 
attention. [1]


Interesting. I know that people have contributed in the past fixes to 
make PROJ *compilable* with UWP, but as we don't have a CI target for 
that, it is unknown how it behaves at runtime.


GDAL likely fails to build with UWP according to 
https://github.com/OSGeo/gdal/issues/1201


Without a CI target that can be hooked into github action (maybe that 
exists. didn't check), UWP compatibility on the long term is going to 
be hard to achieve.
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:julien.mo...@oslandia.com
EMAIL:juli...@oslandia.com
FN:Julien Moura
NICKNAME:jmo
ORG:Oslandia;
TITLE:Consultant - Ingénieur développeur
N:Moura;Julien;;;
ADR:;;France
URL;VALUE=URL:https://static.geotribu.fr
X-MOZILLA-HTML;VALUE=BOOLEAN:TRUE
UID:c6b195b1-5100-402f-bb73-b312bb7289c0
END:VCARD
___
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