search

geopython / pywps

PyWPS is an implementation of the Web Processing Service standard from the Open Geospatial Consortium. PyWPS is written in Python.
https://pywps.org
MIT License
177 stars 117 forks source link

Backport master to 4.4 #574

Closed cehbrecht closed 3 years ago

cehbrecht commented 3 years ago

Overview

This branch backports the changes on master to pywps 4.4.

Related Issue / Discussion

568

Additional Information

List of integrated PRs:

Skipped PRs:

Contribution Agreement

(as per https://github.com/geopython/pywps/blob/master/CONTRIBUTING.rst#contributions-and-licensing)

coveralls commented 3 years ago

Coverage Status

Coverage remained the same at 0.0% when pulling 4f15fc68d5c1e8166c242326dd47043eb178c805 on cehbrecht:backport-to-4.4 into d593f4a6791ad269e0cd57892ef953eeb7c1ffc8 on geopython:pywps-4.4.

cehbrecht commented 3 years ago

test with emu ... still seems to work.

cehbrecht commented 3 years ago

@tlvu @Zeitsperre Maybe you like to check this PR? We can still improve on pywps-4.4 also after merge ...

Zeitsperre commented 3 years ago

@cehbrecht ~Would you like me to merge #573 into pywps-4.4 before this is merged?~

I have opened a new PR: #575. Feel free to merge at your leisure!

cehbrecht commented 3 years ago

@Zeitsperre @fmigneault Thanks for the review. Please give the pywps-4.4 branch a try ... when there are no complains I can make the 4.4.0 release.

tlvu commented 3 years ago

@cehbrecht sorry I took a day off yesterday, was not able to look at this sooner.

So basically if we diff this branch with master, the only differences would be the jobqueue feature? Everything else are backported? We could merge this branch back into master and it should NOT make a difference?

tlvu commented 3 years ago

Here is how master would change today if pywps-4.4 is merged into master: https://github.com/geopython/pywps/compare/20e1e254a3f7914e555fa89f363d1f6eb5f3895c...e10c99c2c8472287f9463bab49d85f5e7597cac2

Looks like all the changes from 4.2.4 forward are missing on master. Should be a good thing to have on master.

tlvu commented 3 years ago

Here is the reverse diff (if master would merge into pywps-4.4) https://github.com/geopython/pywps/compare/e10c99c2c8472287f9463bab49d85f5e7597cac2...20e1e254a3f7914e555fa89f363d1f6eb5f3895c.

Looks like mostly the jobqueue but there are other changes that I am not familiar with.

fmigneault commented 3 years ago

I feel it would be a great idea to have first the resolution of python 2/3 with minor patches in 4.4. Then, another (maybe major?) version for jobqueue and co. features. This will greatly align with OGC-API / owslib eventual work (https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021/issues/2) that will require the job items.

I have started pointing at pywps-4.4 with this PR https://github.com/crim-ca/weaver/pull/214 And so far it doesn't look like there are any major incompatibilities.

I fear though that the alembic database migration and all other job queue elements would cause a lot of problems on my side, while being unnecessary in weaver's case as jobs already have their own reporting/handling.

cehbrecht commented 3 years ago

I fear though that the alembic database migration and all other job queue elements would cause a lot of problems on my side, while being unnecessary in weaver's case as jobs already have their own reporting/handling.

@fmigneault In the next attempt for the job queue implementation I would prefer to life without alembic database migration. The database is essentially used for the queue and this is just temporary storage.

cehbrecht commented 3 years ago

Here is how master would change today if pywps-4.4 is merged into master: 20e1e25...e10c99c

Looks like all the changes from 4.2.4 forward are missing on master. Should be a good thing to have on master.

I could create a dev-branch from the current master and re-integrate the pywps-4.4 branch. The master should then be the same as pywps-4.4.

tlvu commented 3 years ago

I feel it would be a great idea to have first the resolution of python 2/3 with minor patches in 4.4. Then, another (maybe major?) version for jobqueue and co. features.

I am not suggesting merging master to pywps-4.4 so no jobqueue on 4.4. I am only suggesting merge pywps-4.4 to master so master still contain all the fixes (return to the normal workflow before this divergence).

The 2 compare links I generated is simply for us to audit the changes between master and pywps-4.4 branch.

tlvu commented 3 years ago

Here is how master would change today if pywps-4.4 is merged into master: 20e1e25...e10c99c Looks like all the changes from 4.2.4 forward are missing on master. Should be a good thing to have on master.

I could create a dev-branch from the current master and re-integrate the pywps-4.4 branch. The master should then be the same as pywps-4.4.

I think we simply just need to return to the regular workflow. Correct me if I am wrong but we used to merge all branches back to master so master always have all the cumulative changes?

So when we create new branches from master, we ensure the new branch is not missing anything from any previous published releases?

If what I understood is correct, then after the merge of pywps-4.4 to master, we can fix up the jobqueue on master to your liking @cehbrecht then cut a new branch from there for new release. This assume on master the only thing new vs pywps-4.4 is the jobqueue and nothing else (hence the usefulness of the compare links to see the diff between the branches).

cehbrecht commented 3 years ago

I feel it would be a great idea to have first the resolution of python 2/3 with minor patches in 4.4. Then, another (maybe major?) version for jobqueue and co. features.

I am not suggesting merging master to pywps-4.4 so no jobqueue on 4.4. I am only suggesting merge pywps-4.4 to master so master still contain all the fixes (return to the normal workflow before this divergence).

The 2 compare links I generated is simply for us to audit the changes between master and pywps-4.4 branch.

Right. The job-queue is not on pywps-4.4 ... only in the history of master.

cehbrecht commented 3 years ago

If what I understood is correct, then after the merge of pywps-4.4 to master, we can fix up the jobqueue on master to your liking @cehbrecht then cut a new branch from there for new release.

When me make a new attempt on the job-queue I would do this on a dev branch. We can merge it to master when we are really sure we want to keep it :smile:

The next things that could happen on master (after re-integration of pywps-4.4):

tlvu commented 3 years ago

When me make a new attempt on the job-queue I would do this on a dev branch.

Correct. I did not literally meant any commits direct on master. I mean PR to master instead of PR to pywps-4.4.

Sorry if my message was not clear. Nothing should land on master without a PR.