[pygeoapi] for review: RFC2: Dependency policy

[Tom Kralidis]

On Tue, Nov 28, 2023 at 10:10 AM Ricardo Filipe Soares Garcia da via
pygeoapi <pygeoapi at lists.osgeo.org> wrote:

> Thanks for preparing the RFC, I think pygeoapi needs more of this type of
> stuff :)
> I wish it would be a bit more detailed though. Perhaps I'm just missing
> the context from the discussions that were already had about it, but having
> just read it, I found the text to be very succinct, and was left wanting to
> know more details about the proposal.
>
> More specifically:
>
> 1. With regard to the actual dependency management policy, I must admit I
> did not really understand some parts of it - perhaps it could be a bit more
> verbose, even with one or two examples thrown in there? To elaborate on
> this, when the text mentions that:
>
> "...
> master branch dependencies and requirements shall be consistent against a
> given operating system baseline:
>
> - Ubuntu dependencies
> - pip3 requirements
> - Docker / Docker Compose
> ..."
>
> Excuse my obtuseness, but what does this mean exactly? Is it that the
> master branch shall only rely upon those libraries (and respective
> versions) which can be found on a given OS' baseline repositories, which I
> guess is being proposed to be the current Ubuntu LTS? And then the various
> requirements.txt files and Dockerfile would restrict themselves to the same
> libraries and versions? - I'm not saying I do not agree with such a policy,
> it is just that I did not really understand if it is this or something
> else.
>
>
Yes.  pip3 requirements (at the time of release at least) shall be
available on Ubuntu.  Docker and Docker Compose would be built off Ubuntu
as well.


>
> 2. The RFC mentions that "...Careful consideration shall be given when new
> dependencies are proposed..." but I would like it to elaborate on this with
> points about:
>
> - What would be some criteria for deciding whether an additional
> dependency ought to be added?
>

Based on personal experience, the idea would be (on top of Ubuntu
availability):

- health/pulse of a dependency as a project
- is the dependency really needed?  For example, can the same functionality
be achieved with Python primitives or the standard library, even if less
elegant?



> - What would be the process to follow for when a new dependency is being
> considered or proposed? I think this could be documented somewhere. I see
> this question as being relevant in the context of pygeoapi providers and
> their inclusion as part of the 'core pygeoapi experience' and what would be
> a good policy for inclusion, as it seems most dependencies would come from
> providers. But there are other cases where it could be beneficial to have
> some guidelines - with recent examples being the usage of gunicorn or
> pydantic. Just to be clear, I'm not trying to make the case for inclusion
> of any dependency - this is just so that the whole process becomes a bit
> clearer and easier to adhere to
>
>
This may become a moot point as we evolve to 1.0.  The thinking is that
pygeoapi proper would be a minimal set of plugins with bare / minimal
dependencies, and that a pygeoapi-plugins repository would be a growing
repository where pygeoapi plugins would be maintained / developed.  To be
discussed at our upcoming meetings/sprints.




>
> 3. The RFC mentions that pygeoapi maintainers would provide a master
> branch and additional maintenance branches for each minor and major
> release, with relevant security fixes being backported from master. This
> seems like a substantial increase in maintenance-related work, but I guess
> it may depend on additional details, which the RFC does not provide. Some
> questions I think would be worth considering:
>
>
Yes, I think this approach is needed for the long term viability of
pygeoapi.  It is work, but it is also sustainable and a sign/indicator of a
serious project with a long term commitment.


> - How many simultaneous stable branches do you propose to have in addition
> to master? Does it make sense to keep more than one (which would be the
> latest release)?
>

We would have a stable branch for every major and minor release.  We would
also need a policy of how may branches are supported.  n - 1, for example,
would be a suitable approach.  There will always be exceptions of course
(think a CVE which would need patching and backporting across numerous
previous versions).


> - The RFC mentions a number of dissemination channels (UbuntuGIS, pip3,
> docker, etc) as being officially supported. Do you want to keep all of
> them? Could there be other dissemination channels that make sense
> considering? I imagine that each of these distribution channels would also
> need to be updated whenever a new maintenance version got pushed.
>
>
I think our critical path support is Ubuntu, but yes that doesn't stop us
from providing additional channels (see
https://docs.pygeoapi.io/en/latest/installation.html for example).



> I'm wondering if this last item would not be perhaps more appropriate for
> a post-1.0.0 release? Or maybe be the subject of a different RFC?
>
>
+1 to discuss in another thread/meeting/sprint.

Note that RFC2 has now been updated and now going for PSC vote.



> Anyway, thanks for putting it forth and I hope these help in improving the
> overall document.
>
>

Thank you for your valuable feedback Ricardo!

..Tom


> Best regards
>
>
> Tom Kralidis via pygeoapi <pygeoapi at lists.osgeo.org> escreveu no dia
> terça, 28/11/2023 à(s) 00:09:
>
>> Hi all: as discussed at the OSGeo Community Sprint earlier this month,
>> please find RFC2 [1], for
>> review and discussion.  If/once we update as needed, I will put to a PSC
>> vote for formal approval.
>>
>> Thanks
>>
>> ..Tom
>>
>> [1] https://pygeoapi.io/development/rfc/2
>> _______________________________________________
>> pygeoapi mailing list
>> pygeoapi at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>>
>
>
> --
> ___________________________ ___ __
> Ricardo Garcia Silva
> _______________________________________________
> pygeoapi mailing list
> pygeoapi at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pygeoapi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pygeoapi/attachments/20231231/c3a7ed69/attachment.htm>