Drop composer API from python bindings and mark as deprecated #5486
Conversation
This API will be dropped in 3.2 when the layouts work is complete, so we don't want to be restrained by carrying around all the old composer code for the lifetime for 3.x. This allows us to drop all the composer code for 3.2 without breaking the 3.0 api (at the cost of having no scripting of compositions for 3.0, but that's an acceptable trade off)
nyalldawson
force-pushed
the
drop_composer_api
branch
from
dcb1f9e
to
47352b2
Compare
|
Hmm to understate things, that's a rather unfortunate situation. |
|
Ouch....please can we discuss this before merging and we put out a QGIS 3.0 release with no python bindings for composer :-( There are a whole bunch of plugins that won't be able to be ported to version 3.0 :-( |
|
The alternative option is to move them all to a different module in Python
and add a warning on import. Noting that they will never be maintained and
will go in 3.2.
…On Mon, Oct 30, 2017 at 6:01 PM, Tim Sutton ***@***.***> wrote:
Ouch....please can we discuss this before merging we put out a QGIS 3.0
release with no python bindings for composer :-( There are a whole bunch of
plugins that won't be able to be ported to version 3.0 :-(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5486 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3KAgGkwLHqx1ki7X10ya7LV8KswVks5sxYJKgaJpZM4QJuki>
.
|
|
How about instead we make feature freeze exception for print layouts code? Nyall has done an amazing amount of work already on that and if it could be merged in about a week's time then I think it would be much better than trying to keep the old composer code alive... |
|
@wonder-sk , big +1 from me. Feature freeze is great, especially when seasoned with a few exceptions ;) Joking apart, I definitively see a case here for a one off exception. QGIS 3.0 should ship with layouts so it can be thoroughly tested prior to 3.2. It's just a missed opportunity to ship without it since composers are a thing of the past. Plus, granting a feature freeze to Nyall is a pretty safe bet really. |
|
+1
…On Tue, Oct 31, 2017 at 1:15 AM, Mathieu Pellerin ***@***.***> wrote:
@wonder-sk <https://github.com/wonder-sk> , big +1 from me. Feature
freeze is great, especially when seasoned with a few exceptions ;)
Joking apart, I definitively see a case here for a one off exception. QGIS
3.0 should ship with layouts so it can be thoroughly tested prior to 3.2.
It's just a missed opportunity to ship without it since composers are a
thing of the past.
Plus, granting a feature freeze to Nyall is a pretty safe bet really.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5486 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3BacjS57QOuJbOHEKVaW8H53kAhAks5sxegdgaJpZM4QJuki>
.
|
Unfortunately the layouts refactoring didn't land in time for 3.0, so I'm taking a somewhat drastic action of dropping all composer API from the stable API and Python bindings for 3.0.
This API will be completely dropped in 3.2 when the layouts work is complete, so we don't want to be restrained by carrying around all the old composer code for the lifetime for 3.x.
This allows us to drop all the composer code for 3.2 without breaking the 3.0 api (at the cost of having no scripting of compositions for 3.0, but that's an unavoidable trade off, in my opinion).