[QGIS-Developer] Developer Best Practice Suggestions

[Olivier Dalang]

I'm a big fan of #3 :-)

One gotcha with #2 is if you're working in the Windows filesystem, but run
prepare_commit.sh with WSL, you need to make sure the prepare_commit runs
with git.exe, and not WSL's git, as otherwise it can be extremely slow (so
much that the hook is unusable). In my case I had to change
prepare_commit.sh lines ~54-56 for that (replace git by git.exe).

I also had to comment out lines 85-92 of astyle.sh, as they made the script
not find astyle.

About improving tools, I've never tried it, but heard positively of
https://pre-commit.com/ which could be worth investigating for a
potentially nicer and more cross-platform pre-commit ? I feel it's still a
better approach to run those locally than on github (we'd start to have PR
on PRs, which is a bit hard to follow).

Cheers,

Olivier



On Fri, 20 Nov 2020 at 14:58, DelazJ <delazj at gmail.com> wrote:

> Hi,
>
> While looking for some scripts to automate processes in the doc repo, I
> came across this github action (
> https://github.com/marketplace/actions/git-auto-commit) that basically
> updates a branch based on modifications done in that branch or in another
> one.
> We currently have github actions that check and report wrong styling,
> wrong indentation, missing sip doc, spell checks... And I was wondering
> whether it would make sense to go one step further and at the end of the
> check either open a PR in the fork repo or push the expected changes in the
> branch opening the PR. Maybe this could also be actions people would run in
> their own repo before opening the PR (I don't know how possible it's).
> This will probably help people that fail to have the ideal development
> environment locally (never succeeded on Windows) or that use the github
> editor to have these "secondary" but really annoying issues covered easily.
>
> Just wanted to share
>
> Regards,
> Harrissou
>
> Le jeu. 29 oct. 2020 à 23:52, Nyall Dawson <nyall.dawson at gmail.com> a
> écrit :
>
>> On Fri, 30 Oct 2020 at 08:48, Nyall Dawson <nyall.dawson at gmail.com>
>> wrote:
>> >
>> > On Wed, 28 Oct 2020 at 23:34, C Hamilton <adenaculture at gmail.com>
>> wrote:
>> > >
>> > > I tried submitting my first QGIS core code submission. See
>> > >
>> > > https://github.com/qgis/QGIS/pull/39655
>> > >
>> > > As I was doing the pull request I found out that there were some
>> scripts that should have been run to check the coding style. Unfortunately,
>> those scripts are .sh scripts and I chose to develop on Windows using
>> Visual Studio and as far as I know there isn't a way to run the scripts.
>> > >
>> > > I am on windows, but would I be better off to use something like
>> virtualbox and create a virtual linux development environment? I'm not as
>> good with linux because I haven't used it for over 10 years.
>> > >
>> > > Is there still a way for me to use the Windows development
>> environment, yet make sure I'm able to run all the required scripts to do
>> the checks?
>> >
>> > Yes -- there's two options:
>> >
>> > 1. (more hassle in the long run) Use cygwin and run the scripts
>> > through that. Make sure that you have the "with_astyle" cmake option
>> > enabled in your build too! Cygwin is easy to install, but it will be a
>> > pain to find all the required dependancies for the prepare commit
>> > script (e..g you'll need to get the perl packages)
>> >
>> > 2. (harder initially, less hassle in the long run) Install WSL and a
>> > Ubuntu release through that. Run the prepare commit script inside the
>> > Ubuntu shell. WSL takes a through hoops to install, but there's good
>> > guides out there. After you have the Ubuntu shell available it's easy
>> > to install all the required pacakges for the QGIS prepare commit
>> > scripts.
>>
>> Oh, there's also shitty option #3:
>>
>> 3. Push your branch to github and find out what you need to change
>> through the failing tests. Manually make these changes to files.
>> Repeat.
>>
>> Don't do 3. It's painful for you, painful for all the other devs (who
>> have to wait while your string of commits are run through the ci
>> before other PRs will get a chance), and it's **incredibly**
>> environmentally insensitive. Think of all the wasted CPU cycles and
>> the carbon cost of this approach!
>>
>> Push through the hurdles and you'll find 1 or 2 works, and then you'll
>> never have to deal with the frustration of a development process based
>> on the third approach ;)
>>
>> Nyall
>>
>>
>>
>> >
>> > Personally when I'm doing dev on windows I always use the WSL ubuntu
>> > shell now, as it makes git/etc easier to use anyway!
>> >
>> > Nyall
>> >
>> >
>> >
>> > >
>> > > How have you set up your QGIS development environment?
>> > >
>> > > My code submission got a red flag with indentation so before I do
>> anything more I really need to figure out the best workflow for doing
>> development.
>> > >
>> > > Thanks,
>> > >
>> > > Calvin
>> > > _______________________________________________
>> > > QGIS-Developer mailing list
>> > > QGIS-Developer at 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 at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20201120/63accccb/attachment.html>