Re: [QGIS-Developer] Backporting qt6 sip bindings to 3.34?

[Alessandro Pasotti via QGIS-Developer]

+1

Il sab 10 feb 2024, 00:06 Nyall Dawson via QGIS-Developer <
qgis-developer@lists.osgeo.org> ha scritto:

> Hey list,
>
> What does everyone think about us backporting the python/PyQt6/ directory
> from master to the 3.34 branch? I'm thinking we could do this as
> "orphan"/unused files, with the intention that it would make backporting to
> this branch easier. Obviously it introduces a bunch of "noise" in the repo
> for this branch.
>
> Right now any change to a header which entails an accompanying change to
> the .sip files will not be backportable without merge conflicts, so eg the
> backport bot is rather gutless right now...
>
> Nyall
>
> ___
> 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] Backporting qt6 sip bindings to 3.34?

[Matthias Kuhn via QGIS-Developer]

cannot see anything bad +1

On Sat, Feb 10, 2024 at 12:12 AM Even Rouault via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

>
> Le 10/02/2024 à 00:07, Nyall Dawson via QGIS-Developer a écrit :
> > Hey list,
> >
> > What does everyone think about us backporting the python/PyQt6/
> > directory from master to the 3.34 branch? I'm thinking we could do
> > this as "orphan"/unused files, with the intention that it would make
> > backporting to this branch easier. Obviously it introduces a bunch of
> > "noise" in the repo for this branch.
>
> +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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] Is Continuous Legends the default?

[Catania, Luke A ERDC-RDE-GRL-VA CIV via QGIS-Developer]

I am in process of upgrading my plugin to work in QGIS 3.28.15.  I have layer 
styles that I created in 3.16.16.

I noticed the update to the Properties Symbology setting includes Legend 
Settings...

It seems that continuous legends are the default.  I have layer styles files I 
have do not have this set and when those are applied to my layer, continuous 
legends are on by default so I lose my labels.  That is, my layer style qml 
file does not have the entry below.


___
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] Edit Menu Items missing in 3.28.15

[Catania, Luke A ERDC-RDE-GRL-VA CIV via QGIS-Developer]

I am upgrading my plugin from 3.16.16 to 3.28.15.

I installed 3.28.15 and I don't see the options to Add Circle, Add Rectangle, 
and Add Ellipse option in the Edit Menu.  I see in the documentation:

https://docs.qgis.org/3.28/en/docs/user_manual/introduction/qgis_gui.html#edit

that it is still part of the menu, though there are now submenues, so wondering 
why I don not see those options in the menu.
___
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] Backporting qt6 sip bindings to 3.34?

[Even Rouault via QGIS-Developer]

Le 10/02/2024 à 00:07, Nyall Dawson via QGIS-Developer a écrit :

Hey list,

What does everyone think about us backporting the python/PyQt6/ 
directory from master to the 3.34 branch? I'm thinking we could do 
this as "orphan"/unused files, with the intention that it would make 
backporting to this branch easier. Obviously it introduces a bunch of 
"noise" in the repo for this branch.


+1

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

___
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] Backporting qt6 sip bindings to 3.34?

[Nyall Dawson via QGIS-Developer]

Hey list,

What does everyone think about us backporting the python/PyQt6/ directory
from master to the 3.34 branch? I'm thinking we could do this as
"orphan"/unused files, with the intention that it would make backporting to
this branch easier. Obviously it introduces a bunch of "noise" in the repo
for this branch.

Right now any change to a header which entails an accompanying change to
the .sip files will not be backportable without merge conflicts, so eg the
backport bot is rather gutless right now...

Nyall
___
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] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Richard Duivenvoorde via QGIS-Developer]

On 2/9/24 15:32, Greg Troxel via QGIS-Developer wrote:


So:

   This is about Debian (and hence Ubuntu etc.) doing something unusual,
   vs every other system (Other Linux, Windows, Mac, *BSD, illumos.)


No, not so much. It is more about Python and Linux distro's (and cmake) trying 
to address Python's PEP668 (which is mentioned in the kitware issue):

https://peps.python.org/pep-0668/

and the info about 'Externally Managed Environments' and why distro's are doing 
that:

https://packaging.python.org/en/latest/specifications/externally-managed-environments

Takeway:

- in future(?) distro's will have different places where they put packages in: 
one for distro-packaged, and one for locally packaged.

Probably we will end up with a 'lookup path' in which both are available, but 
the order will change depending on if you install locally via pip or via your 
distro's package manager?

I think we are now in the middle of this transitions, hence the messy look 
sometimes.

Regards,

Richard


___
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] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Greg Troxel via QGIS-Developer]

Richard Duivenvoorde via QGIS-Developer 
writes:

> On 2/9/24 14:24, Greg Troxel via QGIS-Developer wrote:
>> How will this affect builds on other systems?   It seems there is
>> something deeper wrong, and the real problem might be that there are
>> multiple legitimate ways to install things, and that the Find script is
>> deficient.
>> How is it looking?   It would seem that finding the python directory
>> should use some python config mechanism.
>
> There are links to deeper info in my issue comment, so see:
>
> https://gitlab.kitware.com/cmake/cmake/-/issues/25113
>
> which makes it most clear.

Thanks, that helps tremendously but I am not yet fully understanding.

This helped me:

https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin

So:

  This is about Debian (and hence Ubuntu etc.) doing something unusual,
  vs every other system (Other Linux, Windows, Mac, *BSD, illumos.)

  Instead of using the default paths that python uses, they have
  configured python so that things have an extra local in the path, so
  that the prefix is $foo/local when the user asks for it to be $foo.

  This choice on Debian's part is a bug to be worked around.

  Setting DEB_PYTHON_INSTALL_LAYOUT='deb' will set the scheme to
  deb_system which is like posix_default.  This is likely ok if one is
  building a deb, but I am guessing not ok if one is building qgis with
  --prefix=/usr/foo.

  It seems like the right fix is for the cmake support that qgis is
  using to say "if scheme is posix_local, change it to posix_default",
  thus working around the Debian bug.

  However, surely Debian people don't think this is a bug.

  Other python software, build on this system, sees a different path?


It sounds like you are proposing to work around this by setting the env
var in the qgis CI environment, and perhaps to recommend to users, and
maybe even to flip it on for users, which is a workaround.

And in the glorious future, cmake will someone manage this by itself.

(I remain unclear on what happens if someone builds on Debian with
--prefix=/usr/foo, but me being unclear on that is ok.)
___
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] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Richard Duivenvoorde via QGIS-Developer]

On 2/9/24 14:24, Greg Troxel via QGIS-Developer wrote:

How will this affect builds on other systems?   It seems there is
something deeper wrong, and the real problem might be that there are
multiple legitimate ways to install things, and that the Find script is
deficient.

How is it looking?   It would seem that finding the python directory
should use some python config mechanism.


There are links to deeper info in my issue comment, so see:

https://gitlab.kitware.com/cmake/cmake/-/issues/25113

which makes it most clear.

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] QGIS plugin depends on pypi package

[Greg Troxel via QGIS-Developer]

John Lindsay via QGIS-Developer  writes:

> I believe that I've solved my earlier issue with my QGIS plugin, which
> previously relied on a pip package. In order to avoid this dependency,
> I decided to include the Whitebox Workflows wheel in with my
> plugin. Unfortunately, however, this has increased the size of my
> plugin fairly substantially. The issue is that I need to included a
> wheel for each of the four supported operating systems and each are
> about 10MB. My plugin zip file is now a little less than 40MB. When I
> try to upload the new version to the QGIS plugin repo it is telling me
> that the file is too large. Does anyone know what the maximum size of
> a plugin zip file is? Thanks.

I was unaware that there was an explicit list of 4 operating systems
(and perhaps you mean 4 OS-version-CPU tuples, if this is a binary
wheel, even if those function on later os-version-cpu systems).

But even if one accepts a triculture (which I personally don't), then I
would expect you'd need wheels for

  linux-?-x86_64
  linux-?-earmv7
  linux-?-aarch64
  mac-?-x86_64
  mac-?-aarch64
  windows-10-x86_64

which is 6 not 4.  I'm unclear on Windows on ARM (because I choose to be
unclear on Windows :-).  Plus RISC-V is on the horizon.  So this rapidly
becomes unworkable.

(Certainly, I can see that qgis.org delivers binaries of qgis for a
limited set of systems, but qgis the source code obviously ought to be
buildable and runnable on any reasonable system that 99.9% meets POSIX,
plus perhaps a few extensions.)


What happens when you try to install the plugin on a system for which
you don't provide a binary wheel?

I have seen thing like Home Assistant just try "import and if that fails
call pip install" but that is a "this program has sufficient
portability/stability issues needing pinned dependencies that the only
viable path is to run inside a venv" situation.


It also strikes me that binary wheels inside plugins are a security and
licensing issue.  While I don't mean to suggest you are doing anything
improper, I expect plugins to be just python code.  From a licensing
point of view, the plugin has to be GPL and thus any included binary
wheels also have to be provided under the GPL.  If they were a
GPL-compatible permissive license, that then triggers obligatiions for
provide sources that weren't there before, and aren't presenet with "you
need to install X".  Do we have existing practice about this?

___
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] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Greg Troxel via QGIS-Developer]

Richard Duivenvoorde via QGIS-Developer 
writes:

> Hi Devs,
>
> I kept getting the https://github.com/qgis/QGIS/issues/54184 issue: sip not 
> being able to find the Qt package sips: 'QtNetwork/QtNetworkmod.sip' could 
> not be found etc etc

I have not tried to build anything beyond 3.34.3 so far.

> You can fix this with (on Ubuntu or Debian), by using (before your cmake 
> step):
>
> export DEB_PYTHON_INSTALL_LAYOUT=deb
>
> Would it be possible/wise to add this to the standard QGIS build scripts?
>
> For more info/explanation, see 
> https://github.com/qgis/QGIS/issues/54184#issuecomment-1935855984

How will this affect builds on other systems?   It seems there is
something deeper wrong, and the real problem might be that there are
multiple legitimate ways to install things, and that the Find script is
deficient.

How is it looking?   It would seem that finding the python directory
should use some python config mechanism.

On my system this file (3.28) is in

/usr/pkg/lib/python3.11/site-packages/PyQt5/bindings/QtNetwork/QtNetworkmod.sip

which seems like it follows the standard python approach (where choosing
a prefix other than /usr is within standard).

What are the variant places it is ending up in?

Shouldn't the Find script just look in both, if there are two normal
approaches?
___
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 Full Stack Web Developer Report

[Lova Andriarimalala via QGIS-Developer]

Hello everyone,

Please find below a report which details the progress made this week on the 
development of the plugin and feed website.

Merged PRs for the plugin website:

  *   [Deployed] Show review form for style 
managers
  *   [Deployed] Fix icons in style list for 
mobile
  *   [Deployed] Preserve non-ASCII characters when downloading a 
zip
  *   [Deployed] Show the ID in plugin detail 
page
  *   [Deployed] Add note for email usage in the plugin upload 
page
  *   [Deployed] Get static and media root from the 
environments
  *   [Deployed] Fix svg icons display issue in plugin list and plugin 
detail
  *   [Deployed] Multi parent folders 
validator
  *   [Deployed] Update repository url when creating or updating a plugin 
version

Merged PRs for the plugin website:

  *   [Not deployed yet] Subclass OSMWidget to use ol 7.2.2 in Django 
3

Next week, I will work on the email-sending issue for both sites and also try 
to solve some of the issues on the QGIS Django repo.

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, 2 February 2024 at 3:51 PM
To: Lova Andriarimalala 
Subject: Re: QGIS Full Stack Web Developer Report
Hello everyone,

Please find below a report detailing the progress made this week on developing 
the plugin and feed website.

Newly open PRs:

  *   Fix icons in style list for 
mobile: this is for 
#131
  *   Subclass OSMWidget to use ol 7.2.2 in Django 
3: this is another method to fix 
#56

Merged PRs for the plugin website:
Most of these PRs have been deployed on staging.plugins.qgis.org for now. 
Please feel free to check them or submit feedback. We are planning to deploy 
them on the production next week.

  *   [Deployed on staging] Fix/logout on profile 
button
  *   [Deployed] Split media and static 
folders
  *   [Deployed on staging] Preserve non-ASCII characters when downloading a 
zip
  *   [Deployed on staging] Show the ID in plugin detail 
page
  *   [Deployed on staging] Add note for email usage in the plugin upload 
page
  *   [Deployed on staging] Get static and media root from the 
environments
  *   [Deployed on staging] Fix svg icons display issue in plugin list and 
plugin detail
  *   [Deployed on staging] Multi parent folders 
validator
  *   [Deployed on staging] Update repository url when creating or updating a 
plugin version
  *   [Deployed] Show plugins with patch versions in plugin 
list

Merged PRs for the feed website:

  *   [Deployed] Add dbbackups service to 
docker-compose
  *   [Deployed] Show a raw version of the 
feeds
  *   [Deployed] Add content char counter, improve invalid form 
handling
  *   [Deployed] Add a field to specify reviewers when submitting a new feed 
item: needs to configure email 
variables on the server.
  *   [Not yet deployed] Use python 3.8 to install Django 
4 and Upgrade to Django 4 to fix OL 
map: they need other stack updates.

Next week, we will continue the deployment on plugins.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, 26 January 2024 at 4:22 PM
To: Lova Andriarimalala 
Subject: Re: QGIS Full Stack W

[QGIS-Developer] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Richard Duivenvoorde via QGIS-Developer]

Hi Devs,

I kept getting the https://github.com/qgis/QGIS/issues/54184 issue: sip not 
being able to find the Qt package sips: 'QtNetwork/QtNetworkmod.sip' could not 
be found etc etc

You can fix this with (on Ubuntu or Debian), by using (before your cmake step):

export DEB_PYTHON_INSTALL_LAYOUT=deb

Would it be possible/wise to add this to the standard QGIS build scripts?

For more info/explanation, see 
https://github.com/qgis/QGIS/issues/54184#issuecomment-1935855984

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