+1 to use 3.9 as base python. Python community hints that they will drop support for old version faster than now, so the 3.6py is going to be the "old" one soon.
Tomek On Wed, Oct 21, 2020 at 11:02 AM Daniel Gruno <humbed...@apache.org> wrote: > On 21/10/2020 10.42, Tomasz Urbaszek wrote: > > Yesterday I took a deeper look at the api. And if I correctly > > understand, currently we are generating open API spec from python > > code. > > > > If we would like to preserve it, I would like to suggest considering > > the FastAPI framework https://fastapi.tiangolo.com . It has many > > advantages including using native type hints from python 3 for data > > validation as well as generating OpenAPI spec. > > mhmm, I was even hoping to go as far as py3.9 for annotations to help > "documenting as you code" :) I am very much for a type hint solution, > especially as we could use mypy for tests then. > > > > > Tomek > > > > On Mon, Oct 19, 2020 at 9:02 PM Tomasz Urbaszek <turbas...@apache.org> > wrote: > >> > >> Thanks for the replies! > >> > >>> I'm not too concerned about breaking API, we _could_ make the next one > a version 2 with a version 2 API, a clean break from version 1 > >> > >> My main point in preserving the compatibiliy is to be sure that the ui > >> will work as expected. This will also limit the scope of the changes. > >> > >>> Whichever framework we pick, I would prefer if we could auto-generate > the JSON/GraphQL API from the source. > >> > >> +1 for automating as much as possible, probably I would lean to first > >> do the JSON as it is now and the consider adding GraphQL. > >> > >> If there is no objections to merging scanners with server I will do > >> this as a first step. Here is a Github issue so we can manage all the > >> work: > >> https://github.com/apache/kibble/issues/64 > >> > >> As per the ideas - I created issues to keep it for future reference :) > >> > >> Bests, > >> Tomek > >> > >> > >> On Mon, Oct 19, 2020 at 7:54 PM Sharan Foga <sha...@apache.org> wrote: > >>> > >>> Hi Tomek > >>> > >>> Thanks for the initiative and ideas! > >>> > >>> Anything that makes things simpler or easier is OK with me :-) and > consolidating things seems like a good idea. I am guessing that a lot of > the changes would probably be behind the scenes rather than at the user end > - right? > >>> > >>> On the wishlist - I saw a talk by Myrle at ApacheCon@Home and she had > done some initial work linking contributions to affiliation and I mentioned > seeing if that could be something we could look at including into Kibble. I > think we tried to do it with Meta Pony Factor but dont think it is > complete. Anyway lots of ideas to keep us going! > >>> > >>> Thanks > >>> Sharan > >>> > >>> > >>> On 2020/10/18 14:28:33, Tomasz Urbaszek <turbas...@apache.org> wrote: > >>>> Hello all, > >>>> > >>>> I would like to propose a few things that I think are worth > considering: > >>>> > >>>> 1. Merge all three repositories (kibble, kibble-scanners, > >>>> kibble-docker) into one. In this way I think we may simplify > >>>> development, dependency management, and distribution. Our project is > >>>> rather small and increasing places needing management probably won't > >>>> help. > >>>> > >>>> 2. Once we have the API server and scanner in one repo we can make > >>>> Kibble a python package. This will not only simplify installation and > >>>> setup but also may help us create a nice CLI to manage all components > >>>> (setup, server, scanners). By doing this users will be able to run > >>>> something like `kibble server` or `kibble scanners ponymail`. > >>>> > >>>> 3. Rewrite kibble API server to use a framework (for example FastAPI > >>>> which supports OpenAPI specs). This point is probably the hardest one > >>>> to implement as it will require adding tests to preserve compatibility > >>>> with kibble ui. > >>>> > >>>> What do you think? Do you have anything that you would love to see in > >>>> Apache Kibble? :) > >>>> > >>>> Cheers, > >>>> Tomek > >>>> > >> > >> > >> > >> -- > >> > >> Tomasz Urbaszek > >> Polidea | Software Engineer > >> > >> M: +48 505 628 493 > >> E: tomasz.urbas...@polidea.com > >> > >> Unique Tech > >> Check out our projects! > >
