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  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 
 
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:*

1.Add support for renaming plugin name

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

[Lova Andriarimalala via QGIS-Developer]

Dear Julien,

Many thanks for your feedback.

In the new PR, 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 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 
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:  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 
website development for this week.
PRs open:

1.   Add support for renaming plugin 
name

2.   Add command to fix none in search 
results

3.   Show more records, records items per 
page

4.   Specify tag page title and other plugin page 
title

5.   Make LICENSE file as required in plugin 
package

PR merged:

6.   Update dockerfile and requirements for 
production

7.   Update requirements according to 
production

8.   Add geoip2 in production, setting up 
log

9.   Use contry code when testing 
daily_visit.country

Still working on:

1.   Fresh plugin 

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] Embedded styling in some datatypes

[Régis Haubourg via QGIS-Developer]

Hi Bo,
Regarding MapInfo, I know the french ministry of environment has tried
something like this years ago.
It was an attempt to handle the transition period between M and Q.

But honestly the style specifications of each proprietary format are really
hard to interoperate. This leads to partially compatible styles, and data
loss.

SLD was a promise to have a common standard but I think all the developers
that tried to implement conversion utilities have been having hard days.
Maybe except for Slyr by Nyall.

Data can be shared across systems. But styles can be shared with very
limited support and this somewhat negates the work of talented
cartographers.



Le jeu. 23 nov. 2023, 11:51, Bo Victor Thomsen via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi list -
>
> I'm wondering about how to use embedded styling in certain types of file
> formats (like MapInfo Tab). I know its possible to read the embedded
> styling from a Tab fil and then convert it to a styling object in QGIS.
>
> However, what about the other direction ? Take a specific QGIS style
> from the layer styling of a tab file, and and write the specific style
> into the feature, so it will be present if you later open the tab file
> in (gasp!) MapIno ?
>
> The use case would be organisations that have a mixed environment of
> QGIS and MapInfo installations. It would allow QGIS users to create and
> update object in a .tab file and save the file. Later this file - if
> opened in MapInfo (or QGIS) - would be shown with the correct embedded
> styling.
>
> --
> Med venlig hilsen / Best regards
>
> Bo Victor Thomsen
>
> ___
> 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] Plugin publication

[Tim Sutton via QGIS-Developer]

I’ll ping Admire to check it for you.Regards—Tim SuttonKartoza co-founderOpen Source GIS Specialisthttps://kartoza.comNo dia 23/11/2023, às 16:24, Paolo Tormene via QGIS-Developer  escreveu:Dear QGIS developers,I published https://plugins.qgis.org/plugins/svir/version/3.17.4/ on November 6, but I see it is still not approved. Probably it was accidentally missed.Please, may you check it?Thanks very much,PaoloOn Wed, Nov 15, 2023 at 2:21 PM Paolo Tormene  wrote:Hello. Please, may someone approve this? https://plugins.qgis.org/plugins/svir/version/3.16.4/Thank you very much,PaoloOn Mon, Oct 23, 2023 at 10:31 AM Paolo Tormene  wrote:Hello. I'm writing to notify you that on October 11 I uploaded to https://plugins.qgis.org/plugins/svir/ a "stable" and an "experimental" version of my plugin and so far only the experimental one has been approved and made available for downloading. I suppose the other version was neglected by accident. May you check, please?Thank you in advance,Paolo-- 

PAOLO TORMENE 
 senior software developer 
 +39 0382 5169882  

 

GLOBAL EARTHQUAKE MODEL  
working together to assess risk

 

GEM -
globalquakemodel.org 

T -
@GEMwrld 

F -
GEMwrld 
-- 

PAOLO TORMENE 
 senior software developer 
 +39 0382 5169882  

 

GLOBAL EARTHQUAKE MODEL  
working together to assess risk

 

GEM -
globalquakemodel.org 

T -
@GEMwrld 

F -
GEMwrld 
-- 

PAOLO TORMENE 
 senior software developer 
 +39 0382 5169882  

 

GLOBAL EARTHQUAKE MODEL  
working together to assess risk

 

GEM -
globalquakemodel.org 

T -
@GEMwrld 

F -
GEMwrld 
___QGIS-Developer mailing listQGIS-Developer@lists.osgeo.orgList info: https://lists.osgeo.org/mailman/listinfo/qgis-developerUnsubscribe: 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] inf and nan in reclassify algo

[Sebastian Gutwein via QGIS-Developer]

Hi,
I recently discovered by trying likely things that I can use inf, -inf, and
nan in the reclassify algo.
Not being a programmer it wasn't obvious that these would be valid inputs.
I would like to document this.
https://github.com/qgis/QGIS-Documentation/pull/8653

>From my research it seems like these are inherent special values in the
floating point format in C++.
https://en.cppreference.com/w/cpp/language/types

The inf and -inf seem straightforward to use in the reclassify table as max
and min values and nan seems to work to set a range of values to nodata.

Are there any gotchas I'm missing or any other values that can be used and
should be documented?
Thanks
-Bas
-- 
___
Sebastian "Bas* " Gutwein
*rhymes with Josh

Regenerative Design Group
1 Chevalier Ave
Greenfield, Ma 01301
Web: regenerativedesigngroup.com
(631) 241-1018

*Look close, think big, make change. *
___
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] Plugin publication

[Paolo Tormene via QGIS-Developer]

Dear QGIS developers,
I published https://plugins.qgis.org/plugins/svir/version/3.17.4/ on
November 6, but I see it is still not approved. Probably it was
accidentally missed.
Please, may you check it?
Thanks very much,
Paolo

On Wed, Nov 15, 2023 at 2:21 PM Paolo Tormene <
paolo.torm...@globalquakemodel.org> wrote:

> Hello. Please, may someone approve this?
> https://plugins.qgis.org/plugins/svir/version/3.16.4/
> Thank you very much,
> Paolo
>
> On Mon, Oct 23, 2023 at 10:31 AM Paolo Tormene <
> paolo.torm...@globalquakemodel.org> wrote:
>
>> Hello. I'm writing to notify you that on October 11 I uploaded to
>> https://plugins.qgis.org/plugins/svir/ a "stable" and an "experimental"
>> version of my plugin and so far only the experimental one has been approved
>> and made available for downloading. I suppose the other version was
>> neglected by accident. May you check, please?
>> Thank you in advance,
>> Paolo
>> --
>>
>> *PAOLO TORMENE* senior software developer +39 0382 5169882
>>
>> *GLOBAL EARTHQUAKE MODEL * working together to assess risk
>>
>> *GEM -* globalquakemodel.org  *T -*
>> @GEMwrld  *F -* GEMwrld
>> 
>>
>
>
> --
>
> *PAOLO TORMENE* senior software developer +39 0382 5169882
>
> *GLOBAL EARTHQUAKE MODEL * working together to assess risk
>
> *GEM -* globalquakemodel.org  *T -*
> @GEMwrld  *F -* GEMwrld
> 
>


-- 

*PAOLO TORMENE* senior software developer +39 0382 5169882

*GLOBAL EARTHQUAKE MODEL * working together to assess risk

*GEM -* globalquakemodel.org  *T -*
@GEMwrld  *F -* GEMwrld

___
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] wrong VRT layer extent

[PIERRE Sylvain via QGIS-Developer]

Hi,

Trying to simply export VRT layer , getting a wrong extent and exporting only 
extent of first raster part of VRT with this code :

  list_dalles = []

features = layer.selectedFeatures()
for f in features:
file_name = f['NOM_DALLE']+'.tif'
dir_name = f['repertoire']
full_file_name = os.path.join( dir_name, file_name)

if os.path.isfile(full_file_name):
list_dalles.append(full_file_name)

parameters = { 'ADD_ALPHA' : False,
'ASSIGN_CRS' : None,
'EXTRA' : '',
'INPUT' : list_dalles,
'OUTPUT' : outVRTfile,
'PROJ_DIFFERENCE' : False,
'RESAMPLING' : 0,
'RESOLUTION' : 0,
'SEPARATE' : False,
'SRC_NODATA' : '' }

#processing.runAndLoadResults("gdal:buildvirtualraster", parameters)
processing.run("gdal:buildvirtualraster", parameters)

vrtLayer = QgsRasterLayer(full_file_name, "bidon")

QgsProject.instance().addMapLayer(vrtLayer, True)

file_writer = QgsRasterFileWriter(outfile)
provider = vrtLayer.dataProvider()
pipe = QgsRasterPipe()

if not pipe.set(provider.clone()):
print ("Cannot set pipe provider")

print(str(provider.extent()))
file_writer.writeRaster(
pipe,
provider.xSize(),
provider.ySize(),
provider.extent(),
provider.crs())

I don't find anything about that, any idea ?

Thanks

[cid:image001.jpg@01DA1E31.806E1620]
Sylvain PIERRE
Chef de projet système d'information
Direction des Systèmes d'Information et du Développement Numérique
Service Projets et Ingénierie Numérique
Collectivité européenne d'Alsace
Tél : 03 88 76 68 88
sylvain.pie...@alsace.eu
www.alsace.eu
[facebook] [twitter] 
  [insta] 


___
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] Questions regarding the QgsProcessingAlgorithm class

[Bo Victor Thomsen via QGIS-Developer]

Hi list -

I apologize for the cross-posting to this mailing list from qgis-user. 
But I hope, that somebody has the answers to the questions...


I have a couple of (probably dumb) questions on how to use the 
"QgsProcessingAlgorithm" class.


 * A have a lot parameter inputs placed in the "advanced" section af
   the processing input dialog. It's parameters that seldom has to be
   changed.
   How do I present the "Avanced" section /not/ unfolded? The default
   is to unfold this section and thus possibly confuse users by showing
   a lot of seldom changed parameters.

 * One of my input parameters is a "QgsProcessingParameterString"
   parameter that will contain a password.
   Can I obfuscate the parameter input, i.e showing '***' instead
   of the password ?

 * the "QgsProcessingParameterFeatureSource" method creates a drop-down
   with names of layers in the map /and/ a checkbox with the label
   "Selected features only". Is it possible to set the checkmark
   automatically when showing the processing userdialog ? And how ??

--
Med venlig hilsen / Best regards

Bo Victor Thomsen
___
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] Embedded styling in some datatypes

[Bo Victor Thomsen via QGIS-Developer]

Hi list -

I'm wondering about how to use embedded styling in certain types of file 
formats (like MapInfo Tab). I know its possible to read the embedded 
styling from a Tab fil and then convert it to a styling object in QGIS.


However, what about the other direction ? Take a specific QGIS style 
from the layer styling of a tab file, and and write the specific style 
into the feature, so it will be present if you later open the tab file 
in (gasp!) MapIno ?


The use case would be organisations that have a mixed environment of 
QGIS and MapInfo installations. It would allow QGIS users to create and 
update object in a .tab file and save the file. Later this file - if 
opened in MapInfo (or QGIS) - would be shown with the correct embedded 
styling.


--
Med venlig hilsen / Best regards

Bo Victor Thomsen

___
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