Re: aurweb Git repository moved to GitLab
lfleischer at archlinux.org (Lukas Fleischer) schrieb am 24.05.20 um 17:38: The official aurweb Git repository has been moved to our new GitLab instance. The new upstream URL is https://gitlab.archlinux.org/archlinux/aurweb.git For the time being, we will accept aurweb bug reports and requests via the mailing list, Flyspray and the GitLab issue tracker. Patches can be submitted to the mailing list or via GitLab. Features that require a GitLab account (such as creating tickets on GitLab or filing merge requests) are currently only available to members of the Arch Linux staff. I will send another email when this changes. In the meantime, please feel free to update any references to the old Git repository. Best regards, Lukas Hi, a suggestion in case you did not notice: you could do it like the GNOME people. They allow access to their GitLab instance via a GitLab.com login: https://gitlab.gnome.org/users/sign_in?redirect_to_referer=yes (Sign in with GitLab.com). This makes it possible to fork a GNOME repo, create merge requests and comment in issues without having an account for the GNOME GitLab instance itself. Kind regards, Ralph
Re: Tech stack for Python aurweb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2020-05-18 at 17:49 -0400, Lukas Fleischer wrote: > > Everybody involved in these efforts seemed to prefer Flask [1] so > far. > It's a mature micro framework and has a relatively low barrier of > entry. I'm a python programmer for a while now and I really like the small size and simplicity of Flask. But let me give you one advice here. If you're dealing with a more complex application Flask tends to become more complex and very hard to manage. All of a sudden you integrate about 10 Flask addons. Some of them are not well maintained. Some droppen support for others etc. You have to manage all those dependencies. Personally I prefer Django in more complex projects as it comes with everything included. You rarely have to add something to your dependencies. I never understodd the argument about it being too big or heavy. Under normal workloads you don't see any difference. Yes Flasks anwsers a few 100 more requests per minute then Django, but is really important to your project? And even if it is, can't you just spawn another instance of it? My personal rule of thumb is to use Flask for everything simple. When users are involved it immediatly becomes complex and I switch to Django. So for example a small API without user database is good job for flask. A blog like app where I have to deal with users, registrations etc is a good job for Django. - -- Greetings Ricardo Band https:// www.ricardo.band mailto:// em...@ricardo.band xmpp://jab...@ricardo.band -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhyzgFNiV8yZuI1T5Gp1lfQa1gg4FAl7KvxMACgkQGp1lfQa1 gg6Nig//R57GeMhSnux2yqwJs1fJCNwot3tQJMdWTBBsYKAlEq/cEcONsoynDlRR 0TilISlsECN2T4GkdDk5aQGcacgx2CPvdlaBhDCbDd7ik7fjaU+g+/3itt7bduwy qIW83QndTNFAQh+dZO2LX1nzQIb0woPbrNTvA4yuDkoa4zNDQgqayBHP9AKsjvK+ 3qDSy2R2DsnvsXpJcppnGX5uk4q/3HL5AGBWTdO+FFidGwLVAFC4S3RTI2ptbSqL rsHccogOyA9ytTrKV3sILM2ryqVaQIsJUVfST3eyY3uxdnYqiCZEk+LPZdBZDsFU guyq4VfmLDgMvmMa+fCYwb5K3noXcgJtu0RBtFlfQYRKsXUmJioPwJzZu8uRPaGh LTbIPFI+4xqvDF93e2k0sI3zk88ZKVI5sHAohcAE1vghdha3sngsqZTzCR6mllWv QzyEUzyg4CfLAg2fEJeCYIqj3rviL/jonZYbp7rdeBlB6VMcDgLNj1f8d4RETI/e yE0LagwoEkgWFJ8IQV+AabmdsoRBX/XMObjPRolkKK7WlHNWRLsdiS1vY71JTVA0 wi9PhkRsqL2Kt1hLYK1MQk9golZ8ptvhtKYGtLdKEyIPRcoUrHgQyeH8LK8e1hTi fgfSCRDydA/k2LFlO0H7xub+5QV+P5+9lnxxIQwG7qbuqyl1gRk= =3c1A -END PGP SIGNATURE-
Re: Tech stack for Python aurweb
On Mon, 18 May 2020 at 18:10:14, Filipe Laíns wrote: > On Mon, 2020-05-18 at 17:49 -0400, Lukas Fleischer wrote: > > Everybody involved in these efforts seemed to prefer Flask [1] so far. > > It's a mature micro framework and has a relatively low barrier of entry. > > I wouldn't be opposed to other framework, as long as it is mature and > simple (rules out Django), but the obvious choice here seems to be > Flask. Just for the record, since the other email was detached from this thread: Sven made a case for FastAPI here [1]. I think it is an interesting alternative that we should consider before finalizing our decision. [1] https://lists.archlinux.org/pipermail/aur-dev/2020-May/004857.html
Re: Tech stack for Python aurweb
Hi guys, This is just a drive-by suggestion but as I've had my fair share of contact with Python web development, both professional and as a hobby, I thought I'd write something. I've worked with Flask for a long time and it really got my career started so it'll always live in a special place for me but I wouldn't use it for modern projects anymore. Some of the patterns used by Flask and the technologies surrounding it are pretty dated by modern standards (magical globals anyone?). Let me instead suggest you consider FastAPI [0]. I've created a few projects using it and I love it. It has the feel of Flask while being entirely modern and yet doesn't feel bloated at all. Here's my feature top list: - Great documentation (even for outside-of-happy-path cases) - Very fast thanks to async (but you can mix sync and async routes if you want to) - Fully typed (with type-based input validation and marshaling using Pydantic by the same author) which makes it possible to run mypy to good effect - Automatic OpenAPI-based API documentation generation based on the aforementioned types - Testing is very nice - Dependency injection is nicer than using Flask's globals (but don't overuse it!) It doesn't ship with templating but you can easily add it. [1] I'm unlikely to be the one implementing this so it's always your call and I'll try to be helpful whichever framework you go with. Cheers, Sven [0] https://fastapi.tiangolo.com/ [1] https://fastapi.tiangolo.com/advanced/templates/
aurweb Git repository moved to GitLab
The official aurweb Git repository has been moved to our new GitLab instance. The new upstream URL is https://gitlab.archlinux.org/archlinux/aurweb.git For the time being, we will accept aurweb bug reports and requests via the mailing list, Flyspray and the GitLab issue tracker. Patches can be submitted to the mailing list or via GitLab. Features that require a GitLab account (such as creating tickets on GitLab or filing merge requests) are currently only available to members of the Arch Linux staff. I will send another email when this changes. In the meantime, please feel free to update any references to the old Git repository. Best regards, Lukas
