Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Nyall Dawson]

On Tue, 20 Oct 2020 at 19:40, Raymond Nijssen  wrote:
>
> If the code snippets are not suitable for the cookbook (because they are
> too odd cases and/or they do not match the cookbook chapters) and you
> decide to put them anywhere else, it would be good practice to add the
> QGIS version number somewhere.

If I can make one other suggestion here, it's that someone manages the
collection of scripts with an "iron fist"!

I've seen previous efforts in collecting PyQGIS helper functions tend
to bloat out and become unmanageable because they end up being a
random collection of very mixed quality and utility. I would
personally attribute this to the collection's maintainers being too
friendly, and accepting the majority of contributions sent in. While
it doesn't sound nice to phrase it this way I think having someone be
very picky and selective about the quality and type of submissions
which are permitted into the collection is ultimately a good thing.

Specifically, I'd suggest putting some firm guidelines in place about
what's acceptable, so that submitters know upfront about what type of
scripts will be accepted and there's no misunderstanding. Some ideas
could be:

- No scripts which duplicate inbuilt PyQGIS (or PyQt) functionality.
(E.g. no scripts for a slightly different way of retrieving project
layers vs what QgsProject gives, no reimplementation of built in
widgets such as field selection combo boxes, etc).
- Scripts should rely as heavily as possible on existing PyQGIS
methods in order to minimise the amount of Python code required
- Since it's a PyQGIS based collection, scripts should use QGIS
classes wherever possible, even if the result might be less
performant. E.g. no use of other libraries like shapely, rasterio,
pandas, raw gdal calls, use QgsNetworkAccessManager instead of the
python requests library, etc. If a script is designed to use these
libraries then I'd suggest having a separate collection for them!

Just my 2c :)
Nyall


>
> Raymond
>
> On 20-10-2020 11:20, Charles Dixon-Paver wrote:
> > I agree that the cookbook is a great resource (which is why I put it
> > first on my list), but I think it's better suited to general examples
> > and giving a solid outline of the best practices. If it's not kept
> > concise, it could become a bit of a convoluted mess, in addition to all
> > the broken code issues Richard raises.
> >
> > As much as it provides a place for scripts that have common use cases,
> > there are some scripts I feel are useful to the community that have no
> > place there, nor do they warrant their own plugin.
> >
> > For example, if you wanted to print out a list of all the typefaces used
> > in a project, AFAIK there's a fair number of nested attributes you have
> > to loop through which I expect a novice would find rather challenging.
> > At the same time, this hardly seems a relevant use case for the
> > cookbook. In GIS, I find a lot of people who aren't developers find
> > themselves with a need to leverage code, so having a way to support
> > copy-paste programmers is beneficial in my view, but maybe that's just me.
> >
> >
> >
> > On Tue, 20 Oct 2020 at 10:59, Richard Duivenvoorde  > > wrote:
> >
> > On 10/20/20 10:48 AM, Jorge Gustavo Rocha wrote:
> >  > Hi,
> >  >
> >  > I think the PyQGIS Cookbook is the perfect place to share these
> > scripts. The Cookbook is not the API reference documentation. It is
> > the place to share solutions for common problems using the QGIS API.
> >
> > While I agree with this, note that it currently is not 'simple' to
> > paste some scripts in the cookbook.
> >
> > Because the cookbook became ... uh a mess, because there were
> > non-running old examples in it, the cookbook is now build in a way
> > that the examples IN the cookbook are actually ran/tested
> > (against/in a Docker QGIS instance). This means that if some api
> > changes, the build of the cookbook of the examples using that api
> > would make the build fail. Which is a good check.
> >
> > But... it also means that 'just copy pasting' some handy examples is
> > not so easy. You have to make sure that there is data to work with,
> > or make some mockup first to be able an example etc etc...
> >
> > So: yes, the cookbook is a good place to showoff use of PyQGIS
> > examples (and to show the use of (sometimes not so intuitive) PyQGIS
> > api)... but for practical examples, it takes (for an average PyQGIS
> > user) maybe too much energy?
> >
> > OR (not sure if that is possible) we should add some 'sketchy' page
> > where indeed people can add working examples and which are not
> > tested... (and which will probably become stale and nobody cares to
> > fix them... like the old cookbook examples)
> >
> > Not sure what others think about this though...
> >
> > Regards,
> >
> > Richard Duivenvoorde
> > 

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Charles Dixon-Paver]

This is why I mentioned snibox, as it's the best self hosted platform I've
found of the bunch for this sort of thing... They have a demo app:

https://snibox.github.io/docs/demo.html

I'm +1 for Raymond's suggestion on versioning, however I think we need a
decent convention for this that makes it easier for someone from the future
to build an AI-driven collect-and-search-all-the-scripts web scraper and
data discovery platform. That convention probably belongs in the cookbook.

I think if we make a good template for snibox you could achieve quite a lot
(especially if we include some custom maintenance-bot DSL system in the
template comments). Spam and trolling might still be an issue though.

Alternatively dokuwiki, github wiki (or similar) might be suitable... But
even those have steeper learning curves and aren't as usable or
discoverable as a copy-paste scenario.

In any event, the platform may need infrastructure, moderation and
curation, which could be challenging.

My intermediary solution was that each user makes their own (or
collaborative between some users) repo which stores the scripts as files,
then have a central curated list which links to repos with interesting or
useful data. This is a simple solution that scales with little to no
effort. It is much more geared towards curated and maintained collections
though.

Tagging, labelling and discovery of items is still a bit terrible within a
GitHub repo though. At best I could suggest something like the data table I
placed at https://zacharlie.github.io/svg4qgis-registry/ that reads the
meta from an index at
https://github.com/zacharlie/svg4qgis/blob/master/svg-registry.json

I think you could easily extend this with csv tags or something (and dress
it up a whole lot from being a 30-minute patch job). I feel it's a
kind-of-horrible-but-relatively-effective method of metadata management and
data discovery. I just don't think it would scale all that well. But that
could be up to each repo owner to maintain or decide how to implement
discovery (outside of standard GitHub search).


On Tue, 20 Oct 2020 at 16:23,  wrote:

> Thanks for a really thoughtful overview of the issues.
>
> I don't think Stack Overflow or any of the Stack Exchange sites are the
> right way to go. In addition to your gamification objections (to which I
> add the obsessive "that's two questions" objections), it's just not a
> focused place to put snippets (or gists as it's called in other places).
>
> Adding to the cookbook doesn't seem right either, since it makes the
> cookbook too diffuse and fills it with so many examples it becomes
> distracting. Add in the fact that the cookbook examples have to be runnable
> in the test harness and require action on a pull request and the hurdles
> become too high.
>
> My preferred solution would be some sort of lightly moderated snippet/gist
> manager that doesn't require any special privileges beyond perhaps
> registration to provide an impediment to spamming. Github gists don't seem
> to have tags so we'd need to establish some sort of convention for
> embedding "tags" in comments. Perhaps someone who is familiar with online
> gist managers can suggest an approach.
>
>
> On 10/20/2020 1:34 AM, Charles Dixon-Paver wrote:
>
> Personally I feel like this outlines a greater problem of snippet sharing
> in many developer communities and is not a problem that is well suited to
> the resource sharing plugin, or even a single traditional GitHub repo.
>
> My personal approach was to set up a subdirectory on GitHub with code
> snippets and add a pyqgis subdirectory (although I don't have a useful
> collection of things yet). I don't really like gists for something I want
> to maintain or have discoverable, so I use this dedicated repo instead. I
> would suggest if you plan on creating a number of different snippets that
> you create a similar one, or if you want to collaborate or make an
> occasional contribution then suggest an alternative.
>
> From my experience with the community it seems like a lot of the most
> useful snippets are scattered throughout conversations on the mailing
> lists, or within stack overflow. When working with the Esri platform and
> Web App Builder, there were a couple of repositories with custom widgets
> etc but the GeoNet forum was also probably the biggest resource for types
> of things like code snippets, although it had similar limitations to what
> I've experienced with pyqgis, perhaps with slightly better discoverability
> since I only really looked in one place and if I couldn't find something I
> didn't waste extra time searching across various platforms.
>
> Personally, I dislike stack overflow for a number of reasons. For one,
> I've found it's platform gamification has always led to a weird passive
> aggressive attitude from community members. The GIS site seems a lot more
> welcoming, but as a general rule, I just straight up don't like the
> platform because of this. The amount of unnecessary question re

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Hernán De Angelis]

This is an interesting discussion. I am an outsider in that I do not use 
PyQGIS particularly often. However, based on similar experiences, I can 
feel I can add my two cents.


Any repository (software or otherwise!) requires a maintenance plan, 
active maintainer(s) and a search tool of sorts to be useful. Otherwise 
chances are that it will soon turn into a graveyard of code that no one 
will want to use.


In my opinion, one can distinguish the following cases and solutions in 
this discussion:


1. code that solves a sufficiently general spatial problem: best 
included in the main code as a function and maintained as such.


2. snippet that solves a sufficiently general use case: treated as 
either (1) or included in the cookbook


3. snippet that solves a particular case of potential general interest: 
describe in an appendix to cookbook or a wiki in a very general way so 
that potential users can adapt it.


/H.



On 2020-10-20 16:23, qgis-u...@stripfamily.net wrote:

Thanks for a really thoughtful overview of the issues.

I don't think Stack Overflow or any of the Stack Exchange sites are 
the right way to go. In addition to your gamification objections (to 
which I add the obsessive "that's two questions" objections), it's 
just not a focused place to put snippets (or gists as it's called in 
other places).


Adding to the cookbook doesn't seem right either, since it makes the 
cookbook too diffuse and fills it with so many examples it becomes 
distracting. Add in the fact that the cookbook examples have to be 
runnable in the test harness and require action on a pull request and 
the hurdles become too high.


My preferred solution would be some sort of lightly moderated 
snippet/gist manager that doesn't require any special privileges 
beyond perhaps registration to provide an impediment to spamming. 
Github gists don't seem to have tags so we'd need to establish some 
sort of convention for embedding "tags" in comments. Perhaps someone 
who is familiar with online gist managers can suggest an approach.



On 10/20/2020 1:34 AM, Charles Dixon-Paver wrote:
Personally I feel like this outlines a greater problem of snippet 
sharing in many developer communities and is not a problem that is 
well suited to the resource sharing plugin, or even a single 
traditional GitHub repo.


My personal approach was to set up a subdirectory on GitHub with code 
snippets and add a pyqgis subdirectory (although I don't have a 
useful collection of things yet). I don't really like gists for 
something I want to maintain or have discoverable, so I use this 
dedicated repo instead. I would suggest if you plan on creating a 
number of different snippets that you create a similar one, or if you 
want to collaborate or make an occasional contribution then suggest 
an alternative.


From my experience with the community it seems like a lot of the most 
useful snippets are scattered throughout conversations on the mailing 
lists, or within stack overflow. When working with the Esri platform 
and Web App Builder, there were a couple of repositories with custom 
widgets etc but the GeoNet forum was also probably the biggest 
resource for types of things like code snippets, although it had 
similar limitations to what I've experienced with pyqgis, perhaps 
with slightly better discoverability since I only really looked in 
one place and if I couldn't find something I didn't waste extra time 
searching across various platforms.


Personally, I dislike stack overflow for a number of reasons. For 
one, I've found it's platform gamification has always led to a weird 
passive aggressive attitude from community members. The GIS site 
seems a lot more welcoming, but as a general rule, I just straight up 
don't like the platform because of this. The amount of 
unnecessary question reformats and edits for points is just painful 
to witness. The system itself has pretty funky issues as well - like 
flagging questions as duplicates but not providing links to those 
duplicates. Or where the OP directly posts links to duplicates but 
explicitly states the solutions don't work, only to have their 
question closed anyway... In any event, I think there's a lot of 
people like me that only end up there when Google/ DuckDuckGo takes 
us there... Which leads to the typical stack overflow issue of all 
code being horribly outdated and nothing actually works. Most of the 
snippets I find on SO are for QGIS 2 anyway. It's also not pyqgis 
specific.


The mailing lists themselves I find have poor code discoverability, 
but I don't think a forum would resolve this and would likely 
just fragment the community further.


For personal use, the best tool I've found for snippet management has 
been https://github.com/snibox/snibox 
 but I don't know how well that 
scales. I used to use dokuwiki too, but it takes a lot of effort to 
format stuff and is more of a publication tool, but I don't see a 
quality wiki being m

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[qgis-user]

  
  
Thanks for a really thoughtful overview of the issues.

I don't think Stack Overflow or any of the Stack Exchange sites are
the right way to go. In addition to your gamification objections (to
which I add the obsessive "that's two questions" objections), it's
just not a focused place to put snippets (or gists as it's called in
other places). 

Adding to the cookbook doesn't seem right either, since it makes the
cookbook too diffuse and fills it with so many examples it becomes
distracting. Add in the fact that the cookbook examples have to be
runnable in the test harness and require action on a pull request
and the hurdles become too high.

My preferred solution would be some sort of lightly moderated
snippet/gist manager that doesn't require any special privileges
beyond perhaps registration to provide an impediment to spamming.
Github gists don't seem to have tags so we'd need to establish some
sort of convention for embedding "tags" in comments. Perhaps someone
who is familiar with online gist managers can suggest an approach.


On 10/20/2020 1:34 AM, Charles Dixon-Paver wrote:

  
  Personally I feel like this outlines a greater
problem of snippet sharing in many developer communities and is
not a problem that is well suited to the resource sharing
plugin, or even a single traditional GitHub repo.


My personal approach was to set up a subdirectory on GitHub
  with code snippets and add a pyqgis subdirectory (although I
  don't have a useful collection of things yet). I don't really
  like gists for something I want to maintain or have
  discoverable, so I use this dedicated repo instead. I would
  suggest if you plan on creating a number of different snippets
  that you create a similar one, or if you want to collaborate
  or make an occasional contribution then suggest an
  alternative.


From my experience with the community it seems like a lot
  of the most useful snippets are scattered throughout
  conversations on the mailing lists, or within stack overflow.
  When working with the Esri platform and Web App Builder, there
  were a couple of repositories with custom widgets etc but the
  GeoNet forum was also probably the biggest resource for types
  of things like code snippets, although it had similar
  limitations to what I've experienced with pyqgis, perhaps with
  slightly better discoverability since I only really looked in
  one place and if I couldn't find something I didn't waste
  extra time searching across various platforms.


Personally, I dislike stack overflow for a number of
  reasons. For one, I've found it's platform gamification has
  always led to a weird passive aggressive attitude from
  community members. The GIS site seems a lot more welcoming,
  but as a general rule, I just straight up don't like the
  platform because of this. The amount of unnecessary question
  reformats and edits for points is just painful to witness. The
  system itself has pretty funky issues as well - like flagging
  questions as duplicates but not providing links to those
  duplicates. Or where the OP directly posts links to duplicates
  but explicitly states the solutions don't work, only to have
  their question closed anyway... In any event, I think there's
  a lot of people like me that only end up there when Google/
  DuckDuckGo takes us there... Which leads to the typical stack
  overflow issue of all code being horribly outdated and nothing
  actually works. Most of the snippets I find on SO are for QGIS
  2 anyway. It's also not pyqgis specific.


The mailing lists themselves I find have poor code
  discoverability, but I don't think a forum would resolve this
  and would likely just fragment the community further.


For personal use, the best tool I've found for
  snippet management has been https://github.com/snibox/snibox
  but I don't know how well that scales. I used to use dokuwiki
  too, but it takes a lot of effort to format stuff and is more
  of a publication tool, but I don't see a quality wiki being
  maintained without significant effort.


Your question has prompted me to set up a https://github.com/zacharlie/awesome-pyqgis
  repository.


This way we can collectively maintain an up to date list of
  resources for PyQGIS, including up to date links for
  documentation, tutorials and training, and links to people's
  repositor

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Raymond Nijssen]

If the code snippets are not suitable for the cookbook (because they are 
too odd cases and/or they do not match the cookbook chapters) and you 
decide to put them anywhere else, it would be good practice to add the 
QGIS version number somewhere.


Raymond

On 20-10-2020 11:20, Charles Dixon-Paver wrote:
I agree that the cookbook is a great resource (which is why I put it 
first on my list), but I think it's better suited to general examples 
and giving a solid outline of the best practices. If it's not kept 
concise, it could become a bit of a convoluted mess, in addition to all 
the broken code issues Richard raises.


As much as it provides a place for scripts that have common use cases, 
there are some scripts I feel are useful to the community that have no 
place there, nor do they warrant their own plugin.


For example, if you wanted to print out a list of all the typefaces used 
in a project, AFAIK there's a fair number of nested attributes you have 
to loop through which I expect a novice would find rather challenging. 
At the same time, this hardly seems a relevant use case for the 
cookbook. In GIS, I find a lot of people who aren't developers find 
themselves with a need to leverage code, so having a way to support 
copy-paste programmers is beneficial in my view, but maybe that's just me.




On Tue, 20 Oct 2020 at 10:59, Richard Duivenvoorde > wrote:


On 10/20/20 10:48 AM, Jorge Gustavo Rocha wrote:
 > Hi,
 >
 > I think the PyQGIS Cookbook is the perfect place to share these
scripts. The Cookbook is not the API reference documentation. It is
the place to share solutions for common problems using the QGIS API.

While I agree with this, note that it currently is not 'simple' to
paste some scripts in the cookbook.

Because the cookbook became ... uh a mess, because there were
non-running old examples in it, the cookbook is now build in a way
that the examples IN the cookbook are actually ran/tested
(against/in a Docker QGIS instance). This means that if some api
changes, the build of the cookbook of the examples using that api
would make the build fail. Which is a good check.

But... it also means that 'just copy pasting' some handy examples is
not so easy. You have to make sure that there is data to work with,
or make some mockup first to be able an example etc etc...

So: yes, the cookbook is a good place to showoff use of PyQGIS
examples (and to show the use of (sometimes not so intuitive) PyQGIS
api)... but for practical examples, it takes (for an average PyQGIS
user) maybe too much energy?

OR (not sure if that is possible) we should add some 'sketchy' page
where indeed people can add working examples and which are not
tested... (and which will probably become stale and nobody cares to
fix them... like the old cookbook examples)

Not sure what others think about this though...

Regards,

Richard Duivenvoorde
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org 
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Charles Dixon-Paver]

I agree that the cookbook is a great resource (which is why I put it first
on my list), but I think it's better suited to general examples and giving
a solid outline of the best practices. If it's not kept concise, it could
become a bit of a convoluted mess, in addition to all the broken code
issues Richard raises.

As much as it provides a place for scripts that have common use cases,
there are some scripts I feel are useful to the community that have no
place there, nor do they warrant their own plugin.

For example, if you wanted to print out a list of all the typefaces used in
a project, AFAIK there's a fair number of nested attributes you have to
loop through which I expect a novice would find rather challenging. At the
same time, this hardly seems a relevant use case for the cookbook. In GIS,
I find a lot of people who aren't developers find themselves with a need to
leverage code, so having a way to support copy-paste programmers is
beneficial in my view, but maybe that's just me.



On Tue, 20 Oct 2020 at 10:59, Richard Duivenvoorde 
wrote:

> On 10/20/20 10:48 AM, Jorge Gustavo Rocha wrote:
> > Hi,
> >
> > I think the PyQGIS Cookbook is the perfect place to share these scripts.
> The Cookbook is not the API reference documentation. It is the place to
> share solutions for common problems using the QGIS API.
>
> While I agree with this, note that it currently is not 'simple' to paste
> some scripts in the cookbook.
>
> Because the cookbook became ... uh a mess, because there were non-running
> old examples in it, the cookbook is now build in a way that the examples IN
> the cookbook are actually ran/tested (against/in a Docker QGIS instance).
> This means that if some api changes, the build of the cookbook of the
> examples using that api would make the build fail. Which is a good check.
>
> But... it also means that 'just copy pasting' some handy examples is not
> so easy. You have to make sure that there is data to work with, or make
> some mockup first to be able an example etc etc...
>
> So: yes, the cookbook is a good place to showoff use of PyQGIS examples
> (and to show the use of (sometimes not so intuitive) PyQGIS api)... but for
> practical examples, it takes (for an average PyQGIS user) maybe too much
> energy?
>
> OR (not sure if that is possible) we should add some 'sketchy' page where
> indeed people can add working examples and which are not tested... (and
> which will probably become stale and nobody cares to fix them... like the
> old cookbook examples)
>
> Not sure what others think about this though...
>
> Regards,
>
> Richard Duivenvoorde
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Richard Duivenvoorde]

On 10/20/20 10:48 AM, Jorge Gustavo Rocha wrote:
> Hi,
> 
> I think the PyQGIS Cookbook is the perfect place to share these scripts. The 
> Cookbook is not the API reference documentation. It is the place to share 
> solutions for common problems using the QGIS API.

While I agree with this, note that it currently is not 'simple' to paste some 
scripts in the cookbook.

Because the cookbook became ... uh a mess, because there were non-running old 
examples in it, the cookbook is now build in a way that the examples IN the 
cookbook are actually ran/tested (against/in a Docker QGIS instance). This 
means that if some api changes, the build of the cookbook of the examples using 
that api would make the build fail. Which is a good check.

But... it also means that 'just copy pasting' some handy examples is not so 
easy. You have to make sure that there is data to work with, or make some 
mockup first to be able an example etc etc...

So: yes, the cookbook is a good place to showoff use of PyQGIS examples (and to 
show the use of (sometimes not so intuitive) PyQGIS api)... but for practical 
examples, it takes (for an average PyQGIS user) maybe too much energy?

OR (not sure if that is possible) we should add some 'sketchy' page where 
indeed people can add working examples and which are not tested... (and which 
will probably become stale and nobody cares to fix them... like the old 
cookbook examples)

Not sure what others think about this though...

Regards,

Richard Duivenvoorde
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Jorge Gustavo Rocha]

Hi,

I think the PyQGIS Cookbook is the perfect place to share these scripts.
The Cookbook is not the API reference documentation. It is the place to
share solutions for common problems using the QGIS API.

Regards,

Jorge

Às 08:34 de 20/10/20, Charles Dixon-Paver escreveu:
> Personally I feel like this outlines a greater problem of snippet
> sharing in many developer communities and is not a problem that is
> well suited to the resource sharing plugin, or even a single
> traditional GitHub repo.
>
> My personal approach was to set up a subdirectory on GitHub with code
> snippets and add a pyqgis subdirectory (although I don't have a useful
> collection of things yet). I don't really like gists for something I
> want to maintain or have discoverable, so I use this dedicated repo
> instead. I would suggest if you plan on creating a number of different
> snippets that you create a similar one, or if you want to collaborate
> or make an occasional contribution then suggest an alternative.
>
> From my experience with the community it seems like a lot of the most
> useful snippets are scattered throughout conversations on the mailing
> lists, or within stack overflow. When working with the Esri platform
> and Web App Builder, there were a couple of repositories with custom
> widgets etc but the GeoNet forum was also probably the biggest
> resource for types of things like code snippets, although it had
> similar limitations to what I've experienced with pyqgis, perhaps with
> slightly better discoverability since I only really looked in one
> place and if I couldn't find something I didn't waste extra time
> searching across various platforms.
>
> Personally, I dislike stack overflow for a number of reasons. For one,
> I've found it's platform gamification has always led to a weird
> passive aggressive attitude from community members. The GIS site seems
> a lot more welcoming, but as a general rule, I just straight up don't
> like the platform because of this. The amount of unnecessary question
> reformats and edits for points is just painful to witness. The system
> itself has pretty funky issues as well - like flagging questions as
> duplicates but not providing links to those duplicates. Or where the
> OP directly posts links to duplicates but explicitly states the
> solutions don't work, only to have their question closed anyway... In
> any event, I think there's a lot of people like me that only end up
> there when Google/ DuckDuckGo takes us there... Which leads to the
> typical stack overflow issue of all code being horribly outdated and
> nothing actually works. Most of the snippets I find on SO are for QGIS
> 2 anyway. It's also not pyqgis specific.
>
> The mailing lists themselves I find have poor code discoverability,
> but I don't think a forum would resolve this and would likely
> just fragment the community further.
>
> For personal use, the best tool I've found for snippet management has
> been https://github.com/snibox/snibox but I don't know how well that
> scales. I used to use dokuwiki too, but it takes a lot of effort to
> format stuff and is more of a publication tool, but I don't see a
> quality wiki being maintained without significant effort.
>
> Your question has prompted me to set up
> a https://github.com/zacharlie/awesome-pyqgis repository.
>
> This way we can collectively maintain an up to date list of resources
> for PyQGIS, including up to date links for documentation, tutorials
> and training, and links to people's repositories. If something like
> this already exists and my list is redundant, please someone let me
> know so I can delete it before we put any significant work into it,
> and share something better so that the community knows about it.
>
> I'm open to other suggestions.
>
> Regards
>
>
> On Tue, 20 Oct 2020 at 00:38,  > wrote:
>
> Is there a place where folks can contribute scripts that others
> might find useful? I know about the Resource Sharing plug-in,
> which is a way to point to a repository one is maintaining. I'm
> thinking more of a common repository where some might contribute
> the odd script. There's an archived git repository in
> qgis/QGIS-Processing->scripts, but that's no longer active.
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org 
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
-- 
Email Signature
Logo  
*Geomaster*
*Jorge Gustavo Rocha* | Software Engineer
*e:*j...@geomaster.pt | *m:*+351 910 333 888
*g:*41.54094,-8.40490 | *v: *510

Re: [Qgis-user] Shared/common library for PyQGIS scripts

[Charles Dixon-Paver]

Personally I feel like this outlines a greater problem of snippet sharing
in many developer communities and is not a problem that is well suited to
the resource sharing plugin, or even a single traditional GitHub repo.

My personal approach was to set up a subdirectory on GitHub with code
snippets and add a pyqgis subdirectory (although I don't have a useful
collection of things yet). I don't really like gists for something I want
to maintain or have discoverable, so I use this dedicated repo instead. I
would suggest if you plan on creating a number of different snippets that
you create a similar one, or if you want to collaborate or make an
occasional contribution then suggest an alternative.

>From my experience with the community it seems like a lot of the most
useful snippets are scattered throughout conversations on the mailing
lists, or within stack overflow. When working with the Esri platform and
Web App Builder, there were a couple of repositories with custom widgets
etc but the GeoNet forum was also probably the biggest resource for types
of things like code snippets, although it had similar limitations to what
I've experienced with pyqgis, perhaps with slightly better discoverability
since I only really looked in one place and if I couldn't find something I
didn't waste extra time searching across various platforms.

Personally, I dislike stack overflow for a number of reasons. For one, I've
found it's platform gamification has always led to a weird passive
aggressive attitude from community members. The GIS site seems a lot more
welcoming, but as a general rule, I just straight up don't like the
platform because of this. The amount of unnecessary question reformats and
edits for points is just painful to witness. The system itself has pretty
funky issues as well - like flagging questions as duplicates but not
providing links to those duplicates. Or where the OP directly posts links
to duplicates but explicitly states the solutions don't work, only to have
their question closed anyway... In any event, I think there's a lot of
people like me that only end up there when Google/ DuckDuckGo takes us
there... Which leads to the typical stack overflow issue of all code being
horribly outdated and nothing actually works. Most of the snippets I find
on SO are for QGIS 2 anyway. It's also not pyqgis specific.

The mailing lists themselves I find have poor code discoverability, but I
don't think a forum would resolve this and would likely just fragment the
community further.

For personal use, the best tool I've found for snippet management has been
https://github.com/snibox/snibox but I don't know how well that scales. I
used to use dokuwiki too, but it takes a lot of effort to format stuff and
is more of a publication tool, but I don't see a quality wiki being
maintained without significant effort.

Your question has prompted me to set up a
https://github.com/zacharlie/awesome-pyqgis repository.

This way we can collectively maintain an up to date list of resources for
PyQGIS, including up to date links for documentation, tutorials and
training, and links to people's repositories. If something like this
already exists and my list is redundant, please someone let me know so I
can delete it before we put any significant work into it, and share
something better so that the community knows about it.

I'm open to other suggestions.

Regards


On Tue, 20 Oct 2020 at 00:38,  wrote:

> Is there a place where folks can contribute scripts that others might find
> useful? I know about the Resource Sharing plug-in, which is a way to point
> to a repository one is maintaining. I'm thinking more of a common
> repository where some might contribute the odd script. There's an archived
> git repository in qgis/QGIS-Processing->scripts, but that's no longer
> active.
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user