Django forks

201 views
Skip to first unread message

jp...@yourlabs.org

unread,
Apr 16, 2017, 9:27:34 AM4/16/17
to Django users
Hello everybody !

Anybody maintaining a Django fork and open for contributions ?

I want to fix problems that have been recurrent for me over the last decade, and that Django doesn't want to fix for ideological reasons.

So, if I don't find a fork that's open for contributions I will make my own.

TYIA
Best
Jamesie
<3

Andréas Kühne

unread,
Apr 17, 2017, 6:21:16 AM4/17/17
to django...@googlegroups.com
Hi,

Just out of curiosity, what is the problem that you are having?

Regards,

Andréas

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b45a3224-e8bc-481b-97a3-d8aa554b3dd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jamesie Pic

unread,
Apr 17, 2017, 10:58:41 AM4/17/17
to django...@googlegroups.com
Dear Andréas,

During the past decade, I have fought that model fields do not have
usable form fields out of the box.

"Django doesn't want to couple a JS framework", is what I remember
from discussions. For me, having JS enabled form fields does not mean
**removing** support for pure-HTML form fields, so, nobody would be
actually "coupled with a JS framework". And, supporting one JS
framework doesn't mean Django couldn't support other framework
neither.

I'd like to try a Django fork that LOVES javascript and out of the box
experience. Currently, the philosophy in Django is "if it can be in an
app then it should be in an app", which opposes what "improving ootb
experience" means for me.

Also, I'd like it to make it easier for newbies to install Django
projects, I've posted about this in a thread about
DJANGO_SETTINGS_FILE on django-dev.

And of course, I'd like a fork that's easy to contribute to, iterate
with, so that features can mature outside of Django before being
proposed upstream. I'm up for helping others on their features too of
course ;)

Best,
Jamesie
<3

Matthew Pava

unread,
Apr 17, 2017, 11:04:06 AM4/17/17
to django...@googlegroups.com
Something you may want to consider is web2py. It has a lot out of the box.
http://www.web2py.com/
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAC6Op1_TS58kQUnDv0_3vXtF%3DbnsUaqtOe7zq2f8kKe4XBsssw%40mail.gmail.com.

Vijay Khemlani

unread,
Apr 17, 2017, 11:06:07 AM4/17/17
to django...@googlegroups.com
Django is essentially a backend development framework (essentially receive http request, make http response)

Ruby on Rails tried to integrate with a javascript "framework" in its time (Prototype / Scriptaculous if I remember correctly) and it exploded on their faces in my humble opinion.

On Mon, Apr 17, 2017 at 12:01 PM, Matthew Pava <Matthe...@iss.com> wrote:
Something you may want to consider is web2py.  It has a lot out of the box.
http://www.web2py.com/



-----Original Message-----
From: django...@googlegroups.com [mailto:django-users@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Monday, April 17, 2017 9:58 AM
To: django...@googlegroups.com
Subject: Re: Django forks

Dear Andréas,

During the past decade, I have fought that model fields do not have usable form fields out of the box.

"Django doesn't want to couple a JS framework", is what I remember from discussions. For me, having JS enabled form fields does not mean
**removing** support for pure-HTML form fields, so, nobody would be actually "coupled with a JS framework". And, supporting one JS framework doesn't mean Django couldn't support other framework neither.

I'd like to try a Django fork that LOVES javascript and out of the box experience. Currently, the philosophy in Django is "if it can be in an app then it should be in an app", which opposes what "improving ootb experience" means for me.

Also, I'd like it to make it easier for newbies to install Django projects, I've posted about this in a thread about DJANGO_SETTINGS_FILE on django-dev.

And of course, I'd like a fork that's easy to contribute to, iterate with, so that features can mature outside of Django before being proposed upstream. I'm up for helping others on their features too of course ;)

Best,
Jamesie
<3

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

m712 - Developer

unread,
Apr 17, 2017, 11:14:09 AM4/17/17
to Jamesie Pic, django...@googlegroups.com
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

Jamesie Pic

unread,
Apr 17, 2017, 11:20:09 AM4/17/17
to django...@googlegroups.com
Matthew, using another framework for new projects would be a tempting
solution, if I was not already maintaining god knows how many Django
apps and projects, and basically had not been capitalizing on Django
itself for the last decade.

Vijay, that RoR failed at it, fails to scare me out, and does not look
like a logic argument *for me*. I'm a lot more comfortable with
failing than with not trying. And even if it was really "impossible"
and that I fail to understand it, I'm not saying it would be better
for you anyway, I'm just looking for other people who think it would
serve them too, hence my initial questions, where are forks ?

Matthew Pava

unread,
Apr 17, 2017, 11:40:45 AM4/17/17
to django...@googlegroups.com
Well, since web2py is in Python, you might find some inspiration there for any extensions or improvements to Django that you would like to see. Why reinvent the wheel, you know?

-----Original Message-----
From: django...@googlegroups.com [mailto:django...@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Monday, April 17, 2017 10:19 AM
To: django...@googlegroups.com
Subject: Re: Django forks

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAC6Op1_4skkvV0PVxAxjsShG%3DD5ryF6uYypwtL2v2UhN8ZGMSw%40mail.gmail.com.

Vijay Khemlani

unread,
Apr 17, 2017, 11:48:12 AM4/17/17
to django...@googlegroups.com
I'm not trying to scare anyone

If you need particular form widgets or fields not readily available in Django I would prefer to write an app that includes them instead of forking the whole framework.

On Mon, Apr 17, 2017 at 12:39 PM, Matthew Pava <Matthe...@iss.com> wrote:
Well, since web2py is in Python, you might find some inspiration there for any extensions or improvements to Django that you would like to see.  Why reinvent the wheel, you know?

-----Original Message-----
From: django...@googlegroups.com [mailto:django-users@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Monday, April 17, 2017 10:19 AM
To: django...@googlegroups.com
Subject: Re: Django forks

Matthew, using another framework for new projects would be a tempting solution, if I was not already maintaining god knows how many Django apps and projects, and basically had not been capitalizing on Django itself for the last decade.

Vijay, that RoR failed at it, fails to scare me out, and does not look like a logic argument *for me*. I'm a lot more comfortable with failing than with not trying. And even if it was really "impossible"
and that I fail to understand it, I'm not saying it would be better for you anyway, I'm just looking for other people who think it would serve them too, hence my initial questions, where are forks ?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

Jamesie Pic

unread,
Apr 17, 2017, 12:07:07 PM4/17/17
to django...@googlegroups.com
On Mon, Apr 17, 2017 at 5:47 PM, Vijay Khemlani <vkhe...@gmail.com> wrote:
> If you need particular form widgets or fields not readily available in
> Django I would prefer to write an app that includes them instead of forking
> the whole framework.

That's why I've been writing AND maintaining apps such as
django-autocomplete-light and like, a lot, lot, lot of others. But
still, it's always the same code in projects just to override an
unusable default form field with something that is usable, in my case.

You are free to not consider it a problem you want fixed, when Django
renders a ForeignKey form field as a select input with millions
options, or when user submits a form that doesn't validate and has to
re-upload a file, or when a user is fighting with a datetime input, or
with env-vars based settings.

Wouldn't it be easier to discuss about solutions, if we already had a
few forks out there that have been iterating on solutions for the last
years ?

Matthew Pava

unread,
Apr 17, 2017, 12:14:42 PM4/17/17
to django...@googlegroups.com
You are the author of DAL? Nice to meet you! We use that! We do use version 2 of it, though. We couldn't find a very important feature for us to upgrade to v3: a text autocomplete that is not based on a pk of a model. Also, unfortunately, with the release of Django 1.11, the autocompletes from v2 do not render properly. I haven't had time to look into it, though.



-----Original Message-----
From: django...@googlegroups.com [mailto:django...@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Monday, April 17, 2017 11:06 AM
To: django...@googlegroups.com
Subject: Re: Django forks

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAC6Op1-6Wzhru1iqPxXi8FQeFPjSgf2r8CJ5u2C%2B92ZAAuXiJQ%40mail.gmail.com.

Jamesie Pic

unread,
Apr 17, 2017, 12:26:08 PM4/17/17
to django...@googlegroups.com
Nice to meet you Matthew <3 That's really funny, because the reason
I'm currently in this is because I'm trying to honor a promise I made
to the community (and myself tbh ^^) when I abandoned v2 in favor of
v3.

v2 has really sound features, "just make an autocomplete for this
model by default", helped a lot.

But, the code that did that was too much work because it was a lot of
working around Django internals. Do you have any idea, the effort it
was, to maintain this at all ?

https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/forms.py

Even then, you had to use a custom modelform, when it should just be a
default, I mean, are you **ever** going to want a select box to render
with a million options ? No, no, no a thousand times no, right ? ;)

About the feature you're missing in v3, it seems like one of the most
recent features that was contributed:

http://django-autocomplete-light.readthedocs.io/en/master/tutorial.html#autocompleting-based-on-a-list-of-strings

Is that what you're talking about ?

Matthew Pava

unread,
Apr 17, 2017, 12:39:11 PM4/17/17
to django...@googlegroups.com
Django 1.11 made a major change to widget rendering. I am wondering if this would help you significantly in your quest. The widget is rendered with a template. It would seem you could include the JavaScript in that template.

But you are right; it is quite frustrating when I'm going to the admin page for a model with a foreign key, and it takes 2 minutes to render because it's rendering the string for 100,000 records to put in a select box. Then I have to go back and change them to raw ID fields so that such attempts do not stop me from working efficiently. Perhaps the Django team can reconsider that feature.

And, yes, that looks like the feature I was looking for. I will try updating my project soon. I do prefer the autocomplete light widget over the select2 widget.



-----Original Message-----
From: django...@googlegroups.com [mailto:django...@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Monday, April 17, 2017 11:26 AM
To: django...@googlegroups.com
Subject: Re: Django forks

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAC6Op19jWZsJr2oHEDJ4HMPFUdjFKdcEpyMP2QXNmrRaqzmYYA%40mail.gmail.com.

Óscar M. Lage

unread,
Apr 17, 2017, 2:25:37 PM4/17/17
to Django users


On Mon, Apr 17, 2017 at 18:07:07 (UTC+2), Jamesie Pic escribió:
On Mon, Apr 17, 2017 at 5:47 PM, Vijay Khemlani <vkhe...@gmail.com> wrote:
> If you need particular form widgets or fields not readily available in
> Django I would prefer to write an app that includes them instead of forking
> the whole framework.

That's why I've been writing AND maintaining apps such as
django-autocomplete-light and like, a lot, lot, lot of others[...]

I'm more or less in the same "mood", taking a look to other solutions (mostly cruds, admin generators etc...) working with other frameworks I think there is a big difference with Django right now. But instead of reinvent the wheel I thought it was better to contribute in any way (I assume you did the same with DAL and others) with a more friendly crud generator, extensible, with custom widgets and easy to add more widgets and kind of fields:

- Date, Time and DatetimePickerWidget 
- ColorPickerWidget
- Editor widget (ckeditor...)
- Select2
- Image cropping
- Forms with tabs and wrappers of fields (crispy-forms)
- Support for inlines + search...


My 2cents, regards!

Jamesie Pic

unread,
Apr 17, 2017, 3:29:59 PM4/17/17
to django...@googlegroups.com
The admin's fine of course, because it has javascript.

But then when using django-filter in django-rest-framework or anything
else that relies on django defaults then the party is over and the
fight for usability begins again.

I feel that in a majority of the cases, it's not for something I want,
but for something that's just usable.

In these cases, I am frustrated because this blocks me from moving on
to building something I want.

It doesn't make sense *for me*, to have to override all form classes
in the world, to replace something that's not usable by something
that's usable.

If I'm overloading something, it should be to "add value", not to
"make it usable", in my personal, own opinion.

My point is indeed not necessarily to bake new fields in the core. We
should be able to share as much as possible with upstream Django ! But
at least I need hooks in Django code to be able to override the
defaults form fields.

And everything I proposed on django-dev since the fall of DAL v2 had a
defect or another that just prevented it from going forward.

I'm not saying they should have accepted my proposals, I'm just saying
that I want to be able to iterate on something, whatever that is. And
it has to be done outside of Django, based on my understanding of
Django processes. It has to be accepted first, before it can be
deployed. But I need to deploy something and iterate, before I can
convince that it is acceptable :P

About jquery autocomplete light there is a PoC to use JAL on DAL
rather than select2:
https://github.com/yourlabs/django-autocomplete-light/pull/749

I prefer JAL to select2 myself, because of the server side rendering
and simplicity... But we'll have to stick with select2 until we find
money to continue cover JAL with unit tests.

Best,
Jamesie
<3

Jamesie Pic

unread,
Apr 17, 2017, 3:45:28 PM4/17/17
to django...@googlegroups.com
Thanks for the heads up Óscar, really cool app !

Upstream contribution is best yes, but not always possible in Django core.

For example in this case, we need to prove that an implementation is
working before contributing it upstream.

To prove that it works, we need to deploy it and live with it for a
while... hence my question is there any fork maintained by people who
would actually value this research ?

Antonis Christofides

unread,
Apr 18, 2017, 4:34:37 AM4/18/17
to django...@googlegroups.com
I'm really no expert in JS, but I have noticed that now that browsers are much
more compliant than they used to be a few years ago, there is a tendency by some
to avoid JS frameworks altogether and write vanilla JS. For example,
https://gomakethings.com/vanilla-js-guidebook/ (the author is an acquaintance),
and there are more on the same train.

I guess that writing vanilla JS might have the added benefit of being easier to
accept into core Django.

Antonis Christofides
http://djangodeployment.com

Melvyn Sopacua

unread,
Apr 20, 2017, 7:51:20 AM4/20/17
to django...@googlegroups.com

On Monday 17 April 2017 16:37:19 Matthew Pava wrote:

> Django 1.11 made a major change to widget rendering. I am wondering

> if this would help you significantly in your quest. The widget is

> rendered with a template. It would seem you could include the

> JavaScript in that template.

 

You can.

What I don't get is that the label is still coupled with the field instead of the widget. This would've been a chance to move it, so that we can render proper form groups for custom widgets.

 

Oh well.

 

--

Melvyn Sopacua

Jamesie Pic

unread,
Apr 20, 2017, 10:04:05 AM4/20/17
to django...@googlegroups.com
Hi all,

Those of you who use some of my apps know that I don't put inline
javascript code ever in fields, for the reason that it's known to slow
page rendering. Also, it isn't known to help maintainability nor
re-usability. That Django provides this as the only way does not
invalidates that.

Also, overriding default form fields (and of course, classes) all the
time just because I want something that's /usable/, is not acceptable
in my logic. If I have to override something it should be to "add
value", not "make it usable". I'm sorry but it looks like you don't
understand me so I try to repeat myself but it might not work either
:D

I already know how to customize Django forms, as stated earlier, I'm
the author of django-autocomplete-light and have maintained and
supported it for the past 5 years for the community for free, for
sports. My requirement is: I want form fields to be usable out of the
box, without having to override the form class everywhere in the world
(admin, drf, django-filters, and so on) just because I want usable
fields.

Thanks a heap for sharing some of your insight

Best
Jamesie
<3

Matthew Pava

unread,
Apr 20, 2017, 10:10:26 AM4/20/17
to django...@googlegroups.com
Hi Jamesie,
I understand what you want, and I agree, in essence, that the fields should just be useable out of the box. I was just providing an alternative suggestion to creating a whole new fork of Django and if not that, at least some inspiration for what you want to include in that fork.
--Matthew

-----Original Message-----
From: django...@googlegroups.com [mailto:django...@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Thursday, April 20, 2017 9:03 AM
To: django...@googlegroups.com
Subject: Re: Django forks

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAC6Op1_AszLdo4p%2BqVnBtkYAXO3_JYfec8SHROHo03Xp4hNkkw%40mail.gmail.com.

Jamesie Pic

unread,
Apr 20, 2017, 11:00:59 AM4/20/17
to django...@googlegroups.com
Thank you my friend !

Best
Jamesie
<3

Jamesie Pic

unread,
Sep 18, 2017, 1:11:25 PM9/18/17
to django...@googlegroups.com
Hi all,

After taking a ride in Go lang framework world, and coming back with
the idea that I'd still be producing Django projects for the next 3
years, I have started to fix the problems I think are in Django in a
layer that sits on top of it: https://github.com/yourlabs/crudlfap
because I think that in 2017, my framework should let me configure
OOAO things like: permissions on models/fields/objects/views (not in a
table, please), ajax filtered configurable tables, autocompletes,
modern OOTB UI/UX, automatically create new databases and execute
migrations and ask me to create a superuser when I run runserver
(please), and other stuff I won't mention here because this is long
enough. For this reason, I am not longer interested in participating
to a fork.

Best
Jamesie
<3

Jamesie Pic

unread,
Sep 22, 2017, 12:53:11 PM9/22/17
to django...@googlegroups.com
Because Django is so awesome, I'm glad to show off the little framework built upon Django only 4 days of coding later (but after thinking about it for years and being asked by a customer - coming from modern PHP frameworks ecosystem - to implement such a thing in their project).


So, it's not a fork, just a smart pattern and modern default views and templates out of the box.

Please feel free to digress or message me in private if you prefer.

Njoy B)
With <3
Reply all
Reply to author
Forward
0 new messages