Re: [QGIS-Developer] Get rid of Processing scripts in favour of plain alogrithms

2018-01-31 Thread G. Allegri 
Cool! Probably it wasn't clear my suggestion, but that's exactly what I
meant: keep "scripts" but get rid of the special syntax and implement
QgsProcessingAlgorithm subclasses.

Giovanni


Il 1 feb 2018 06:26, "Nyall Dawson"  ha scritto:

> On 31 January 2018 at 18:24, G. Allegri  wrote:
> > I understand your point Victor, and I agree that scripts was a clever
> idea.
> > But:
> >
> >  - with the current shape of Processing (QGIS 3.0) I think the "syntactic
> > sugar" provided by scripts has less relevance. As I can see from the
> > refactoring, there's less automation in parameters conversions and
> > management, and a few new "magic" context variables have been
> introduced. I
> > think scripts now are too similar to plain geoalgorithms, and
> consequently
> > the differences can become misleading and not easily understood.
> >
> >  - syntactic sugar requires maintanance: if a new parameter is
> introduced, i
> > parameters are added or changed, the corresponding translation method for
> > scripts must be updated.
> >
> >  - syntactic sugar requires doc maintanance, while Processing APIs
> > documentation can be mostly automated.
> >
> > Anyway, this is a proposal to be discussed. Meanwhile I will try to
> estimate
> > the work needed to drop (and adapt) the current implementations.
> >
> > PS: @Victor, it's nice to follow Processing's history! C++ (SAGA) -> Java
> > (Sextante) -> Python (Processing) -> C++ (QGIS 3.0)  :D
>
> I'm a bit late to this discussion, but my 2c:
>
> - I actually like the idea of single file script algorithms, and don't
> want to see them go. I can see lots of valid use cases for why they
> are needed. (In particular - I'd love to extend models in future to
> allow embedded script algorithms which are contained just within a
> single model, and not exposed elsewhere).
>
> - It's just the syntax of scripts which I'm not a fan of (for reasons
> well covered above)
>
> Alex has a WIP PR already at https://github.com/qgis/QGIS/pull/6225  -
> stakeholder comments would be welcome here!
>
> 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] Get rid of Processing scripts in favour of plain alogrithms

2018-01-31 Thread Nyall Dawson 
On 31 January 2018 at 18:24, G. Allegri  wrote:
> I understand your point Victor, and I agree that scripts was a clever idea.
> But:
>
>  - with the current shape of Processing (QGIS 3.0) I think the "syntactic
> sugar" provided by scripts has less relevance. As I can see from the
> refactoring, there's less automation in parameters conversions and
> management, and a few new "magic" context variables have been introduced. I
> think scripts now are too similar to plain geoalgorithms, and consequently
> the differences can become misleading and not easily understood.
>
>  - syntactic sugar requires maintanance: if a new parameter is introduced, i
> parameters are added or changed, the corresponding translation method for
> scripts must be updated.
>
>  - syntactic sugar requires doc maintanance, while Processing APIs
> documentation can be mostly automated.
>
> Anyway, this is a proposal to be discussed. Meanwhile I will try to estimate
> the work needed to drop (and adapt) the current implementations.
>
> PS: @Victor, it's nice to follow Processing's history! C++ (SAGA) -> Java
> (Sextante) -> Python (Processing) -> C++ (QGIS 3.0)  :D

I'm a bit late to this discussion, but my 2c:

- I actually like the idea of single file script algorithms, and don't
want to see them go. I can see lots of valid use cases for why they
are needed. (In particular - I'd love to extend models in future to
allow embedded script algorithms which are contained just within a
single model, and not exposed elsewhere).

- It's just the syntax of scripts which I'm not a fan of (for reasons
well covered above)

Alex has a WIP PR already at https://github.com/qgis/QGIS/pull/6225  -
stakeholder comments would be welcome here!

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] Get rid of Processing scripts in favour of plain alogrithms

2018-01-31 Thread Victor Olaya 
Right, I see you your point.

I havent been able to follow the recent developments in Processing,
and i have to admit i am a little bit lost (Nyall has been working too
fast!!). So this is just my opinion, but it might not make sense in
the current situation.

I will try to get up to date as soon as possible :-)

Thanks for your collaboration!

2018-01-31 9:24 GMT+01:00 G. Allegri :
> I understand your point Victor, and I agree that scripts was a clever idea.
> But:
>
>  - with the current shape of Processing (QGIS 3.0) I think the "syntactic
> sugar" provided by scripts has less relevance. As I can see from the
> refactoring, there's less automation in parameters conversions and
> management, and a few new "magic" context variables have been introduced. I
> think scripts now are too similar to plain geoalgorithms, and consequently
> the differences can become misleading and not easily understood.
>
>  - syntactic sugar requires maintanance: if a new parameter is introduced, i
> parameters are added or changed, the corresponding translation method for
> scripts must be updated.
>
>  - syntactic sugar requires doc maintanance, while Processing APIs
> documentation can be mostly automated.
>
> Anyway, this is a proposal to be discussed. Meanwhile I will try to estimate
> the work needed to drop (and adapt) the current implementations.
>
> PS: @Victor, it's nice to follow Processing's history! C++ (SAGA) -> Java
> (Sextante) -> Python (Processing) -> C++ (QGIS 3.0)  :D
>
> All the best,
> Giovanni
>
>
>
> 2018-01-31 8:33 GMT+01:00 Victor Olaya :
>>
>> I like the idea, but i dont think it will mean less code, specially
>> for defining the parameters and outputs. Why not keeping it for those
>> that want to use it this way?
>>
>> Before removing this (in case it's decided to do so), two things to
>> notice:
>>
>> -- There were algorithms (built-in ones) defined this way, so they
>> should be rewritten
>> -- There is a little-known functionality that creates a new plugin
>> from a set of scripts. It should be adapted as well, or removed.
>>
>> Thanks!
>>
>>
>> 2018-01-30 21:41 GMT+01:00 G. Allegri :
>> > I know there are much more important priorities in view of the QGIS 3.0
>> > release.
>> > I will try to implement the idea of Geoalgorithms served by the script
>> > provider and, in case, I'll commit a PR for testing and comments.
>> >
>> > Giovanni
>> >
>> > Il 29 gen 2018 16:44, "Anita Graser"  ha scritto:
>> >>
>> >>
>> >>
>> >> On Mon, Jan 29, 2018 at 2:24 PM, G. Allegri  wrote:
>> >>>
>> >>> What's your opinion
>> >>> ?
>> >>>
>> >>
>> >> +
>> >> 1 for me, as stated in the original thread
>> >>
>> >> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051511.html
>> >>
>> >>
>> >> I think it will be good to unify the approaches.
>> >>
>> >> Regards,
>> >>
>> >> Anita
>> >>
>> >>
>> >>
>> >>
>> >
>> > ___
>> > 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] Get rid of Processing scripts in favour of plain alogrithms

2018-01-31 Thread G. Allegri 
I understand your point Victor, and I agree that scripts was a clever idea.
But:

 - with the current shape of Processing (QGIS 3.0) I think the "syntactic
sugar" provided by scripts has less relevance. As I can see from the
refactoring, there's less automation in parameters conversions and
management, and a few new "magic" context variables have been introduced. I
think scripts now are too similar to plain geoalgorithms, and consequently
the differences can become misleading and not easily understood.

 - syntactic sugar requires maintanance: if a new parameter is introduced,
i parameters are added or changed, the corresponding translation method for
scripts must be updated.

 - syntactic sugar requires doc maintanance, while Processing APIs
documentation can be mostly automated.

Anyway, this is a proposal to be discussed. Meanwhile I will try to
estimate the work needed to drop (and adapt) the current implementations.

PS: @Victor, it's nice to follow Processing's history! C++ (SAGA) -> Java
(Sextante) -> Python (Processing) -> C++ (QGIS 3.0)  :D

All the best,
Giovanni



2018-01-31 8:33 GMT+01:00 Victor Olaya :

> I like the idea, but i dont think it will mean less code, specially
> for defining the parameters and outputs. Why not keeping it for those
> that want to use it this way?
>
> Before removing this (in case it's decided to do so), two things to notice:
>
> -- There were algorithms (built-in ones) defined this way, so they
> should be rewritten
> -- There is a little-known functionality that creates a new plugin
> from a set of scripts. It should be adapted as well, or removed.
>
> Thanks!
>
>
> 2018-01-30 21:41 GMT+01:00 G. Allegri :
> > I know there are much more important priorities in view of the QGIS 3.0
> > release.
> > I will try to implement the idea of Geoalgorithms served by the script
> > provider and, in case, I'll commit a PR for testing and comments.
> >
> > Giovanni
> >
> > Il 29 gen 2018 16:44, "Anita Graser"  ha scritto:
> >>
> >>
> >>
> >> On Mon, Jan 29, 2018 at 2:24 PM, G. Allegri  wrote:
> >>>
> >>> What's your opinion
> >>> ?
> >>>
> >>
> >> +
> >> 1 for me, as stated in the original thread
> >> https://lists.osgeo.org/pipermail/qgis-developer/2018-
> January/051511.html
> >>
> >>
> >> I think it will be good to unify the approaches.
> >>
> >> Regards,
> >>
> >> Anita
> >>
> >>
> >>
> >>
> >
> > ___
> > 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] Get rid of Processing scripts in favour of plain alogrithms

2018-01-30 Thread Victor Olaya 
I like the idea, but i dont think it will mean less code, specially
for defining the parameters and outputs. Why not keeping it for those
that want to use it this way?

Before removing this (in case it's decided to do so), two things to notice:

-- There were algorithms (built-in ones) defined this way, so they
should be rewritten
-- There is a little-known functionality that creates a new plugin
from a set of scripts. It should be adapted as well, or removed.

Thanks!


2018-01-30 21:41 GMT+01:00 G. Allegri :
> I know there are much more important priorities in view of the QGIS 3.0
> release.
> I will try to implement the idea of Geoalgorithms served by the script
> provider and, in case, I'll commit a PR for testing and comments.
>
> Giovanni
>
> Il 29 gen 2018 16:44, "Anita Graser"  ha scritto:
>>
>>
>>
>> On Mon, Jan 29, 2018 at 2:24 PM, G. Allegri  wrote:
>>>
>>> What's your opinion
>>> ?
>>>
>>
>> +
>> 1 for me, as stated in the original thread
>> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051511.html
>>
>>
>> I think it will be good to unify the approaches.
>>
>> Regards,
>>
>> Anita
>>
>>
>>
>>
>
> ___
> 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] Get rid of Processing scripts in favour of plain alogrithms

2018-01-30 Thread G. Allegri 
I know there are much more important priorities in view of the QGIS 3.0
release.
I will try to implement the idea of Geoalgorithms served by the script
provider and, in case, I'll commit a PR for testing and comments.

Giovanni

Il 29 gen 2018 16:44, "Anita Graser"  ha scritto:

>
>
> On Mon, Jan 29, 2018 at 2:24 PM, G. Allegri  wrote:
>>
>> What's your opinion
>> ​?​
>>
>>
> +
> ​1 for me, as stated in the original thread https://lists.osgeo.org/piperm
> ail/qgis-developer/2018-January/051511.html
>
>
> I think it will be good to unify the approaches.
>
> Regards,
>
> Anita
>
>
>
> ​
>
>
___
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] Get rid of Processing scripts in favour of plain alogrithms

2018-01-29 Thread Anita Graser 
On Mon, Jan 29, 2018 at 2:24 PM, G. Allegri  wrote:
>
> What's your opinion
> ​?​
>
>
+
​1 for me, as stated in the original thread https://lists.osgeo.org/
pipermail/qgis-developer/2018-January/051511.html


I think it will be good to unify the approaches.

Regards,

Anita



​
___
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