To whom it may concern, The following is a proposal for a Django-hosted aurweb application. It is meant to be a drop-in replacement for aur.archlinux.org; effectively cloning its user interface and capabilities into a Python Django extension. Following https://patchwork.archlinux.org/patch/1000/, I would like to put together a new aurweb. The current revamped version of archweb runs inside of a django server as a django extension (or app). I would like to do this same thing for `aurweb`. The new django `aurweb` shall support all of the current v1-6 capabilities that aurweb provides, as well as the front-end user website located at https://aur.archlinux.org. It shall be an exact clone from the user's perspective. The major differences between maintaining a PHP vs Django server would be that the Django server would be: 1. Integrated with any Django server and easily removed. 2. Developed via Python, which has vastly more support and familiarity than PHP within the community. 3. Django models, which greatly reduce the complexity of SQL queries inside of `aurweb` backend. 4. Baked-in extendable templates with templatetags. 5. View decorators which enforce requirements of a specific route. No more manually handling $http_data user errors. 6. Everybody loves Python; there will most likely be many more code-base contributions in Python than in PHP. I would like to hear your thoughts on this. If approved, I would love to begin this project within the next few weeks. Thanks, Kevin
On 2/17/19 2:21 AM, Kevin Morris wrote:
The major differences between maintaining a PHP vs Django server would be that the Django server would be:
2.
Developed via Python, which has vastly more support and familiarity than PHP within the community.
6.
Everybody loves Python; there will most likely be many more code-base contributions in Python than in PHP.
This appears like the same point to me. I feel like you're selling this idea really hard on the premise that python == better instead of the hard data points that would favor a django app -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 2/16/19 8:28 PM, Robin Broda wrote:
On 2/17/19 2:21 AM, Kevin Morris wrote:
The major differences between maintaining a PHP vs Django server would be that the Django server would be:
2.
Developed via Python, which has vastly more support and familiarity than PHP within the community.
6.
Everybody loves Python; there will most likely be many more code-base contributions in Python than in PHP.
This appears like the same point to me. I feel like you're selling this idea really hard on the premise that python == better instead of the hard data points that would favor a django app
Maybe it's the same point, but I'm sold anyway. ;) For context: this django proposal was discussed on IRC a bit, and I want it just because it would make it easier to work on aurweb. Going one step further, ISTR some discussion in the past that we'd like to move to python anyway. As for hard data points: The AUR4 git-shell backend, notify scripts, and cron jobs which are used for taking care of the git repositories, maintaining the blacklists, etc. were initially implemented in python as mostly standalone from the web frontend that has existed since 2004. So in practice, using django means we could share code between the backend and frontend, which is particularly interesting to me given the recent case of https://git.archlinux.org/aurweb.git/commit/?id=f1d109e9b6863d924d2cb20f83e4... ... On a personal level, I find the idiosyncrasies of php to be less intuitive than the idiosyncrasies of python, and probably to blame for this: https://git.archlinux.org/aurweb.git/commit/?id=ac29097ce8585b99ebe7c5d9570b... (why is ".=" used for appending instead of "+=" anyway? That thing is way too invisible.) -- Eli Schwartz Bug Wrangler and Trusted User
On Sat, 2019-02-16 at 21:08 -0500, Eli Schwartz wrote:
On 2/16/19 8:28 PM, Robin Broda wrote:
On 2/17/19 2:21 AM, Kevin Morris wrote:
The major differences between maintaining a PHP vs Django server would be that the Django server would be:
2.
Developed via Python, which has vastly more support and familiarity than PHP within the community.
6.
Everybody loves Python; there will most likely be many more code-base contributions in Python than in PHP.
This appears like the same point to me. I feel like you're selling this idea really hard on the premise that python == better instead of the hard data points that would favor a django app
Maybe it's the same point, but I'm sold anyway. ;)
For context: this django proposal was discussed on IRC a bit, and I want it just because it would make it easier to work on aurweb. Going one step further, ISTR some discussion in the past that we'd like to move to python anyway.
It would perhaps make it easy for you to work on it, but that's not true for someone like me. I would like to contribute more to this project myself, but if it's moved to django, I will lose all interest as I have no desire to learn a framework, let alone one for Python. Not that a decision like this needs to be decided over just whether one person will continue to contribute, but this is a reason I won't touch archweb myself.
As for hard data points:
The AUR4 git-shell backend, notify scripts, and cron jobs which are used for taking care of the git repositories, maintaining the blacklists, etc. were initially implemented in python as mostly standalone from the web frontend that has existed since 2004.
So in practice, using django means we could share code between the backend and frontend, which is particularly interesting to me given the recent case of https://git.archlinux.org/aurweb.git/commit/?id=f1d109e9b6863d924d2cb20f83e4...
I'm not really sure if the code as is right now would be appropriate if we moved to Django. Frameworks have an annoying tendency to cause the developer to abandon things that are in conflict or redundant to the framework. This brings up another point, why not just pull many of those functions into PHP? Not that I'm saying it should be done that way (even though it can in many cases), I look at this as a non-issue due to the nature of what those scripts are doing (as in, not generating a web page).
...
On a personal level, I find the idiosyncrasies of php to be less intuitive than the idiosyncrasies of python, and probably to blame for this: https://git.archlinux.org/aurweb.git/commit/?id=ac29097ce8585b99ebe7c5d9570b... (why is ".=" used for appending instead of "+=" anyway? That thing is way too invisible.)
This is because the concept of string concatenation is not really the same as arithmetic addition. Plus this is something probably inspired from Perl. The use of two different operators in this case is actually something I really like about PHP over Python. Plus, that commit looks like it could have easily been overlooked even if += is used over something like .= . Especially since it can be quickly read without care and was also written by one of the maintainers of the project, causing perhaps the guard of careful reading to go down. Mark
On Sat, Feb 16, 2019 at 05:21:56PM -0800, Kevin Morris wrote:
1.
Integrated with any Django server and easily removed.
I'm fine with python, but django? Why not consider a more plug-able approach like flask+sqlalchemy? The arch security tracker runs the stack and AFAIK we are happy with it.
3.
Django models, which greatly reduce the complexity of SQL queries inside of `aurweb` backend.
You get the same flexbility with `flask-sqlalchemy` (any ORM essentially) and any given REST framework. -- Morten Linderud PGP: 9C02FF419FECBE16
On Sat 16 Feb 2019 17:21 -0800, Kevin Morris wrote:
The following is a proposal for a Django-hosted aurweb application. It is meant to be a drop-in replacement for aur.archlinux.org; effectively cloning its user interface and capabilities into a Python Django extension.
Following https://patchwork.archlinux.org/patch/1000/, I would like to put together a new aurweb.
I'm a bit confused. You wrote one patch and you want to rewrite the whole thing now? I've seen this at least three times before with more or less fully developed rewrites. They all failed. They were all written in Python coincidentally.
The current revamped version of archweb runs inside of a django server as a django extension (or app). I would like to do this same thing for `aurweb`. The new django `aurweb` shall support all of the current v1-6 capabilities that aurweb provides, as well as the front-end user website located at https://aur.archlinux.org.
archweb was already written in python for django more than 10 yrs ago. I guess it may not have been an extension (or app), whatever that is. I imagine the porting/migration if any would have been much more trivial than a full rewrite.
It shall be an exact clone from the user's perspective.
This is a very uncompelling reason to rewrite the whole thing.
The major differences between maintaining a PHP vs Django server would be that the Django server would be:
Users don't care about any of your six bullet points.
I would like to hear your thoughts on this. If approved, I would love to begin this project within the next few weeks.
Begin the project now and don't make it the same. Make it better. Nobody is gonna approve vaporware. Steal users from the AUR. Convince people your system really is better. Good luck.
Thank you for the extra CC, that was perfect timing :). To address Foxboron, I would choose Django as a framework purely so that we could integrate it into the same wsgi engine that archweb uses on the current servers and have it work seamlessly. But additionally, Django provides a good baked in user model which we would otherwise have to either implement or use an existing user framework for Flask/SQLAlchemy? I believe that Django is more rigorous in it's approach to handling routes and would require less developer effort to add, modify, or remove features. It is heavier, but I believe that it is more stable when used correctly. Django also provides many automatic handling of sessions (redirection to login, automatic error responses, ...) and it's rest_framework extension is just as simple and robust as anything else. I'm a bit confused. You wrote one patch and you want to rewrite the whole
thing now? I've seen this at least three times before with more or less fully developed rewrites. They all failed. They were all written in Python coincidentally.
No. The patch was merely something that I wanted to help resolve before presenting any kind of proposal like this. It was brought up as an outstanding issue or possible patch to finish up for the RPC protocol. I only wanted to help finish the patch to help out (and I also thought provides would be quite useful). Additionally, I would like to apologize for the fact that the proposal is not as well written as it could be. On Sat, Feb 16, 2019 at 9:08 PM Loui Chang <louipc.ist@gmail.com> wrote:
The following is a proposal for a Django-hosted aurweb application. It is meant to be a drop-in replacement for aur.archlinux.org; effectively cloning its user interface and capabilities into a Python Django extension.
Following https://patchwork.archlinux.org/patch/1000/, I would like to
On Sat 16 Feb 2019 17:21 -0800, Kevin Morris wrote: put
together a new aurweb.
I'm a bit confused. You wrote one patch and you want to rewrite the whole thing now? I've seen this at least three times before with more or less fully developed rewrites. They all failed. They were all written in Python coincidentally.
The current revamped version of archweb runs inside of a django server as a django extension (or app). I would like to do this same thing for `aurweb`. The new django `aurweb` shall support all of the current v1-6 capabilities that aurweb provides, as well as the front-end user website located at https://aur.archlinux.org.
archweb was already written in python for django more than 10 yrs ago. I guess it may not have been an extension (or app), whatever that is. I imagine the porting/migration if any would have been much more trivial than a full rewrite.
It shall be an exact clone from the user's perspective.
This is a very uncompelling reason to rewrite the whole thing.
The major differences between maintaining a PHP vs Django server would be that the Django server would be:
Users don't care about any of your six bullet points.
I would like to hear your thoughts on this. If approved, I would love to begin this project within the next few weeks.
Begin the project now and don't make it the same. Make it better. Nobody is gonna approve vaporware. Steal users from the AUR. Convince people your system really is better. Good luck.
-- Kevin Morris Software Developer Business Inquiries: kevr@coderesistance.com Personal Inquiries: kevr.gtalk@gmail.com Personal Phone: (415) 571-0513 Technologies: C++, Python, Django, Ruby, Rails, ReactJS, jQuery, Javascript, SQL, Redux
participants (6)
-
Eli Schwartz
-
Kevin Morris
-
Loui Chang
-
Mark Weiman
-
Morten Linderud
-
Robin Broda