Re: Proposal to format Django using black

2019-04-22 Thread Jamesie Pic
Thanks for sharing some of your insight.

On Mon, Apr 22, 2019 at 10:57 AM Nick Sarbicki 
wrote:

>  Even moreso if it lowers the barrier to entry (I don't think anyone is
> saying it raises it?).
>

I'm just saying that if "As contributor, I can haz automatic code formatter
to lower the barrier" is precisely the story you want to solve, then black
may not be the only solution you want to consider deeply ;)

Have a great day ;)

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-SfcGf9-Uv-ere92i9%3DGG24s0qkC%2BY7_%3Dc08Zvaw8v2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Proposal to format Django using black

2019-04-22 Thread Jamesie Pic
Just note that the coala python package ( https://coala.io ) seems to be
the alternative to black that will let you make some compromises, might be
worth considering as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18_ZPJS5pm%3DZ%2B%2B3z3O4NZJydEvF75v-FNkmhQw0xjThYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Development story for CBV FormViews using GET

2019-04-18 Thread Jamesie Pic
Hi Kye,

Sorry for mispelling your name above, but it's a really long thread and
non-native. And I can tell, there's rarely a better way than discussing in
foreign languages to make a nice little fool of myself xD This time I will
share my story with CBV, a story with love, and code and aggressive design
patterns in it. This is all because one of you consulting for yourlabs made
a comment about my shitty JS code: it was non aggressive. I've been working
that state of mind and then ...

The first violation I made to any bare common sense was to add support for
magical getters ... now view.url can return the result of view.get_url()

... And then I went on breaking Python by adding support in the type as
well ... now View.url can also return the result of View.get_url()

... At the price of thread safety, I guess I'm lucky it was always an easy
fix "just use the right variable you're allowed to but keep on refactoring"

... And then it became even more obscure when the magical getter also was
able to detect if {V,v}iew.get_url(view) would have not returned anything,
but did set {V,v}iew.url as attribute ... now caching became absolutely
free ...

... And then added a Controller in-between Model and its set of View ...
now Django knows MVC and can generate object level menus with efficient
permission management thanks to the Django permission backend that has so
many plugins or whatever implementation you put to override per controller
or view ...

... And then added a rich experience from out of the box templates because
why not after all django-webpack-loader by @alihazemfarouk is dope to
upgrade front end development workflow to a level like Python ...

... Don't ask what front-end framework cause what matters to me is the
practice of an modular development workflow, not which JS framework ...

... All this because a friend of mine who didn't understand Django, didn't
understand why we should hardcode menu HTML code, and cried in my laps for
help to refactor for days, the first name for the Controller class was
"Drycrud", do you imagine, instanciating a new Drycrud object ? Even more
obscure. Well at least it's named Router for now but in its final version
it needs to be called Controller because it sits between the Model and it's
set of class Based views ...

... So the generic ListView for example is like:
class ListView(mixins.ListMixin, mixins.SearchMixin, mixins.FilterMixin,
mixins.TableMixin, mixins.ObjectsMixin, TemplateView):
def get_object_list(self):
if self.filterset:
self.object_list = self.filterset.qs
else:
self.object_list = self.queryset
if self.search_form:
self.object_list = self.search_form.get_queryset()
return self.object_list
def get_listactions(self):
return self.controller.get_menu('list_action', self.request)

The view.listactions variable allows a view to override programmatically
what items the default list view template will propose for selected items.
It takes the request object for permission checking which is pretty raw but
turns out to just work: router.get_menu() returns a list of View classes of
the same Controller (thus same Model in practice), for which
view.has_perm() returns true. has_perm() is called once the view has been
hydrated with the passed request object in view.request. Your high level
code uses view.object instead of view.get_object(), because get_object()
will already be called automatically as a magic getter

As for get_object_list horror ... hopefully it's the only class in the
whole crudlfap.views.generic that encapsulates this kind of coupling, but
at the same time the coupling in there depends on what the parent mixins
offer and that is quite tricky to get right, but at the end of the day it's
just gluing the mixins together.

Please forgive this horror story from being loaded with absolutely
non-impressive material:

https://gitpitch.com/yourlabs/crudlfap
http://crudlfap--jpic.repl.co/
http://crudlfap.rtfd.io/

Want to share more use cases with CBVs ? Reply to the list now !

Thanks for reading and have a great day ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_bK7PJLBHOJUaUaAFRVtMNVS-J080f2SnUZmfSLzY%2B1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSOC Proposal (Bundler for Django)

2019-04-08 Thread Jamesie Pic
PS: also check how other python frameworks deal with static files,
particularly the cubicweb framework.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18N%3DfJnb5SKUUBgmgVMo33_6QpruBiOCpU8VTb8kh9pxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: GSOC Proposal (Bundler for Django)

2019-04-08 Thread Jamesie Pic
Hi Ashik,
Thanks for your proposal that I find revelant because there needs to be a
new version of staticfiles.

Supporting NPM, one way or another, is the main way to enjoy the same
development workflow with frontend code as with pip. For me it would make
sense to support it, one way or another. {% block extra_js %} overrides
kind of works, but overriding frontend code delivered by an app is far from
convenient

when it involves copying a minified script from an app into an override
static dir and patching that minified code. Also dealing with {{ form.media
}} definitely doesn't cut it, ie. when if you load jquery in your base.html
and a form media also contains a jquery, this means we load the same script
twice, and that also causes issues ie. with plugin loading. So it doesn't
look like anybody would deny that static file management in Django needs an
upgrade.

However, the suggestion to contribute to other existing third party apps is
valid. Before contributing to Django you need to study the current state of
the art in the Django ecosystem, that lives in external projects.
Contribute to those, see why you believe they don't cut it, and make a
write up the existing django static file apps ecosystem, that would be a
great start.

Have a great day

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18N1O6hFnwgrmnw28c_-warB-KMGO68S572xz--9SGGaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Development story for CBV FormViews using GET

2019-03-14 Thread Jamesie Pic
Kyle, is it possible to show the code you are talking about ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-DTUOmh-SB6RB48WZnpwOC20D0hp-f%3D%3DOyDX_Vnevm%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-27 Thread Jamesie Pic
FTR I published my own writeup here:
https://blog.yourlabs.org/post/183077442308/django-js-research-report

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op184WMaf09CD1NqznfCQv%2BqhcMePB8nUdTKpTns1Fejc0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Official Django Docker Container Deprecated

2019-02-27 Thread Jamesie Pic
> most people currently lean towards a microservice architecture and therefore 
> towards flask.
"according to the 2018 JetBrains Developer Survey" and some people.
Why start a project with flask in 2019 instead of Quart which or
Starlette is another question that I suppose is out of the scope of
this mailing list.

Anyway, the point of Docker is to build your own image that supports
both development and production given different runtime parameters.
The agile practice with docker is to build your immutable image in CI,
test it, deploy it to staging, have on-click deployment to production.

The security and best practice documentation from docker are indeed a
lot to grasp, and beginners will most of the time start making
insecure (running as root) and inefficient (fat) images. Therefore for
their security Django might want to document making a docker file,
perhaps based on the alpine image that's the most lightweight.

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-5XHfW6ASmnkU2hHOVzifumLVf-E1ZrAP8%2BpQdKLj-1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-25 Thread Jamesie Pic
On Mon, Feb 25, 2019 at 10:39 PM Jamesie Pic  wrote:
> component = dict(
> template_name='django/forms/widgets/textarea.html',
> script='your/textarea.js',
> style='your/style.css'
> )

Actually do NOT try this, for static i think the more efficient
refactor would be to enable widgets and things to touch
request.static.scripts and request.static.styles, so that scripts that
you load in your parent template would not be re-added by the widgets.
At the same time, programing perimeter for widget statics would
increase since this would no more reduce it to a declarative
structure.

And maybe you want to try to change from templates to python rendering
functions, if not for transpiling or performance, performance, maybe
just for easier reuse across python code in general. But then you
would use a python library that

FTR GDAPS is also having research on this as we speak :
https://gitlab.com/nerdocs/gdaps/issues/2

Have fun

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18G0897i333BgRmcOur5bGGceuAy7ak6XN%3DZ2rmOuW7MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-25 Thread Jamesie Pic
Also in Django maybe try to change things like:

class Textarea(Widget):
template_name = 'django/forms/widgets/textarea.html'

With

component = dict(
template_name='django/forms/widgets/textarea.html',
script='your/textarea.js',
style='your/style.css'
)

Or something component='your.favorite.TextArea', then you could also hack
django.forms.widgets.component to change the default rendering at the
project level. Maybe then distribute more exciting component objects that
accepts this dict interface in pip packages that could work with any python
framework.

Anyway, keep on pursuing your dream stack, always happy to read some
exciting discussions on this matter ;)

Have a great day

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op191PpSz_EZT8H-zSz5cgePAD-j%3DBHQQfCvT0KTgVyJQrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Post mortem on today's packaging error.

2019-02-11 Thread Jamesie Pic
Hi Carlton !

Seems like you're having as much fun as I had when doing releases
manually :D Just sharing some food for thought here.

Nowadays I have it automated and rely on setupmeta to keep myself away
from touching setup.py, and just have to push git tags :
http://github.com/zsimic/setupmeta

Then a silly little script like that to publish to pypi :
https://yourlabs.io/oss/shyml/blob/master/shyml/sh.yml

All python modules on yourlabs.io/oss have this kind of setup ... of
course you're still stuck on jenkins so I can understand it's not as
flexible as say gitlab-ci or drone-ci, but there's probably also a
way.

Hope this helps

Keep up the good work, you'll make it !

Have a great day

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_rgn8BnHHS-0%2B05yMKFi5g%2Bq%2BKmHZVz1-SP-sgxY-%3D3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-07 Thread Jamesie Pic
Well, there's also Graphene. It's at least REST or GraphQL.

Le mar. 5 févr. 2019 à 03:09, Cristiano Coelho  a
écrit :

> Pointing to Django Rest Framework should be more than enough. Anyone
> starting a project with Django and a SPA/JS architecture, will pretty much
> end up with DRF. Correct me if I'm wrong.
>
>
> El lunes, 4 de febrero de 2019, 19:52:42 (UTC-5), Maciek Olko escribió:
>>
>> I didn't find this topic being discussed before.
>>
>> It seems to me to be good idea to place "How do I get Django and my JS
>> framework to work together?" or similar question and answer to it in FAQ in
>> Django's docs.
>>
>> Having very big popularity of JS frameworks now it is indeed very common
>> question being asked or searched on the Internet. Such question for ReactJS
>> has 65k views on StackOverflow [1].
>>
>> The answer could briefly explain that one can make use of Django backend
>> and produce API to be consumed by JS clients. Probably it would be good to
>> link to Django REST API project as a suggestion for big projects.
>>
>> What do you think about such addition to FAQ?
>>
>> Regards,
>> Maciej
>>
>> [1]
>> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/87fb9a35-b274-4d62-b17c-602114719ad5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_WxEiVOML8za6UfYWyFintJx60TqvPsF-d7SNzeTYm%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-05 Thread Jamesie Pic
Throwing in some food for thought that may be worth mentioning and that we
like to play with:

- django-webpack-loader merged code chunking recently
- transcrypt allows coding ie with react in Python, transcrypt also
supports webpack
- chp is a project that aims to replace templates as we know them by
functions, it's a minimal port of react, it relies on transcrypt for
isomorphic support

>From my pov it seems webpack is establishing as a standard worth
supporting, but code chunking is really nice to have for a better loading
experience.

In pure Django we used to chunk by extending a script block in non-base
templates.

Le mar. 5 févr. 2019 à 11:17, Carlton Gibson  a
écrit :

> I think this topic is very interesting.
>
> Two sides of it:
>
> * Static files handling
> * APIs
>
> Curtis is right, there are other options but, Django REST Framework is
> (whilst not perfect) pretty solid on the API front. I think Django has a
> good story here.
> It's pretty hard not to find DRF if you follow any guide, or any searching
> at all.
>
> The static files story is a little different. It seems to me we don't tell
> the best story there.
>
> Rails has two things which we could be envious of, even if we didn't want
> to copy exactly:
>
> * The frontend framework integration that's already been mentioned.
> * The very easy "Ajax your form", with controllers (i.e. for us "generic
> views") automatically handling ajax form submissions.
>
> Both these features get users further quicker in these aspects than we are
> able to offer.
>
> We struggle to think of areas for improvements (re GSoC for example) but
> maybe here is an area.
>
> This ties into Claude's proposal here:
> https://groups.google.com/d/topic/django-developers/KYmNnvwXDUI/discussion
>
> My own story is, I've had lots of success with, and still use, Django
> Compressor.
>
>- At it's simplest you just map a content type to a shell command to
>run and then include your Sass/Less/React/Elm/whatever files in your HTML
>(with script or link tags, almost in the old-school way).
>- In development these are processed (& cached) per request.
>- For deployment you just run an offline compression task (management
>command) and then upload the files.
>- That's it.
>
> It's not a coverall approach — a frontend engineer will come along and
> totally replace Compressor with whatever is this week's Top Javascript
> Build System™ BUT it is a good 80:20: it lets me do something (that
> approximates) respectable, without knowing hardly anything about the latest
> frontend hotness. (GNU Make FTW! )
>
> I think if we were to offer something out-of-the-box that got as far as
> Compressor, or further, we'd:
>
>- satisfy most of our users,
>- allow yet more to get off the mark quickly,
>- and... well... those that need the full frontend toolchain would
>still be free to use it.
>
> I worry we'd never get anything like this into core... but I think it
> would be good. (As I say, I think it's one area where we are lacking/behind
> the competition.)
>
> Kind Regards,
>
> Carlton
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/49deee81-0230-48a0-8c2a-b12eb0956810%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_zPHFamYefkLPkYiRTnXjAbrX9wLa9XkQmYv5foNJKYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Potential suspension of Channels development

2019-01-30 Thread Jamesie Pic
On Sun, Jan 20, 2019 at 3:19 PM Shrawan Poudel  wrote:
>
> Hello, i am interested in helping in this project. Please guide thought the 
> process for helping .
> I have been using these projects in many of my Production app .

Watch the repository on github, read the pull requests and ask
questions about submitted code where you feel that it could be
improved.

Look at the issues, try to reproduce them, submit a pull request with a fix.

On Mon, Jan 21, 2019 at 12:27 AM Andrew Godwin  wrote:
>
> Instead, I think Django should focus on a good async path for HTTP - views, 
> ORM, templates, and the like. This is what I want to get done if I can get my 
> time and energy back!

There's nothing I wouldn't do to see that happening !

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-9TE7b21ooh0BHstNL1hunHzdV-mQ%3DnV5OGgZw_Szk%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: thoughts for Django fellowship applicants

2019-01-13 Thread Jamesie Pic
Hello Tim,

Debugging over ip with non-natives is very hard indeed. Thank you for
completing your mission with extremely high achievement. Your engagement is
the most beautiful inspiration for any fellow. I hope to read other posts
from you even long after.

I'm deeply sorry for the times when I have projected my frustration over
internet on you, and the mailing list.

Please all accept my most sincere apology.

Best regards, friend

PS: if you travel, our hackerspace has OpenCouch and great reference ;)
https://couchsurfing.com/jpic

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18V%3Dxv6YwiAN6Ww4LxnzTXJDWNhhsdCCuK94F2YK%3DUmaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Database connection retry

2018-12-15 Thread Jamesie Pic
Nope, uwsgi in docker...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op198KTy6x7LFPnQZcVn0bC1a8_Va%2BZvxMRtKNDuFrZWJWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Database connection retry

2018-12-14 Thread Jamesie Pic
Hi all,

Sorry to bump this, but I didn't find another thread, and I'm pretty sure
re-trying the database connection is the sane thing to do.

Otherwise, Django will remain in failed state after reboot in some cases:
psycopg2.OperationalError: FATAL:  the database system is starting up

It would be better if Django could tolerate this situation and retry, then
the server would be reboot proof.

At least, show a 500 page until the DB server has started, would be more
reasonnable.

Are you sure Django should not be a bit a bit more tolerant with databases
starting up ?

Or should we open a ticket ?

Thanks in advance for your reply

Have a great weekend

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18ET_ZZs_XBQou70sJL9vo2fsk2BL57q4j-U-j5H_d4oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Widening participation (Thoughts from DjangoCon)

2018-12-11 Thread Jamesie Pic
Thanks Josh, love your link, seems like it dates from 2017 during the
period when GitLab UI was redesigned. But GitLab is still emerging as
a standard tool no matter what.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19Das4BwaiFSo8pRK6s0pcbSp5ECSDH83aoVyEe6DD3tA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Widening participation (Thoughts from DjangoCon)

2018-12-11 Thread Jamesie Pic
Gitlab should be mentioned as a vastly superior alternative to trac +
GitHub + jenkins.

Le mar. 11 déc. 2018 à 14:01, Hanne Moa  a écrit :

> Whenever I've had to move from one issue-system to another, the main
> pain point has always been issue/comment ownership[*]. This is because
> many systems want a login-capable, verified user for every single
> person that have ever made an issue or comment. If there is no 1-to-1
> mapping, the issue/comment is often owned by the importing user, and
> the username/email of the original contributor is mangled into the
> issue/comment-text itself.
>
> This looks so nice for an issue with 50+ different contributors when
> wind up being owned by the same user. Robert explains to Robert that
> Robert's patch won't work with Roberts latest PR because Robert pulled
> the wrong commit that Robert made to update the dependencies that
> Robert discovered needed to be updated because Robert found a security
> flaw, with apologies to Robert. There's usually no way to search for
> the actual contributors either. It is as if importing to such
> issue-systems are an after thought. Starting out with a design where
> user and contributor are two different but potentially linked objects
> would have solved the problem *correctly*.
> 
>
> [*] There are no doubt problems other than this, it's just the one
> that bugs me the most. Especially since the solution so often is "Drop
> all history, start from scratch."
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19n-sfO2mLFGiXs0ohodCHK-%2BYEw9k7_n1r%3DJfq7VAFZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.contrib.auth CLI

2018-10-11 Thread Jamesie Pic
Hi smart nerds,

I'm sorry if my sense of humour was too much to handle for you.

But to compensate I offer the unfrustrating python CLI package, and at the
same time most awesome CLI CRUD for Django to my knowledge, on
yourlabs.io/oss/clilabs

One last thing, verrry important for the record, in case anybody reading
wants to learn eXtreme DevOps: making a django app is an horrible
suggestion, because automation tool should be automatically made available,
pip install is automatable so it works, we can have an automatic pre-task
that installs it, but adding to INSTALLED_APPS is a manual step, which
makes django-apps and management commands that require in-project
installation a horrible mistake, typical of "going one step forward and
then one step back" in automation.

Exactly why this is a python package, with support for django, from the
beginning. Maybe if django supports a system like pluggy this can change,
but for now making this a django app would be counter productive.

Have a great day

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-sPCvhS_cqzZ8L4QqjdT83CnKhgqwZ2516tiiV8LobUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.contrib.auth CLI

2018-10-11 Thread Jamesie Pic
Forgot a note about extreme devops:

It's when you have an automatic deployment per feature branch (example
).

GitLab even has a feature to help it called dynamic environments
,
currently they only support Kubernetes out of the box, but it's also
possible with playlabs, the result of open sourcing the playbooks we've had
in production this year at the government.

Have a great day, and most importantly: have FUN :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_%3D5zR1Q%3DQ-XvqaC9sUdo-22Bk%3DTXwUEUJA4qe68%3DFa5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.contrib.auth CLI

2018-10-11 Thread Jamesie Pic
Hello Ludovic,

I'm glad this little joke tickled you, sorry for being that childish but
sometimes I can't help it (I don't see how anybody could feel rationnaly
offended since this joke talking about me). In reality, I've just been
automating Django deployments for 10 year. So, if it takes 50 years to be
an expert in something, I'm definitely too young to be an expert in
anything ;)

Yes I have package deployment automation, because I maintain more than 30
open source packages, most of them for Django, on PyPi alone, some on NPM.
The reason it's not the point, is that my CM aims at automating deployment
of django projects, not of "django projects that have added my poor django
app that provides a fixed createsuperuser and a removeuser CLI".

So, if i'm doing this automation again (and I am), it will be in the CM,
**not** in an app, because in this case, it **doesn't make sense to do it
in an app, it would just make my CM more incompatible with OOTB Django**.
It's the third time I'm explaining this, please excuse me for giving up as
from where i'm standing it seems nobody is able to counter that objection,
but I really feel like it's being purposely ignored.

We never have two deploys "one local one production", we always have "one
local one staging one production" so that's three.

Ludovic, nowadays in the DevOps world we don't "automate deployment of
requirements.txt" anymore, we don't "compile a virtualenv on the target"
anymore, because we have separated "build-time" from "test-time" and
"deploy-time", thanks to containers.

This doesn't need to "react to changes or user feedback", the needs have
been the same for 10 years, add/remove users in an automated way.
Currently, we're injecting code in django-admin shell.

Oh what's that final line of your email you're accusing me of being passive
aggressive :D

I do not have any more energy for this contribution, I'll just add it to my
little monster crudlfap because that's my layer for any new project, as I
have exigence for Controllers to refactor view code, and working
ForeignKey/FileField forms out of the box (that means JS), now is the time
crudlfap also compensate for Django's lack of OOTB automation feature,
despite how basic they can be.

Case closed as far as I'm concerned.

My apologies to all the community for being unable to defend this proposal.
Note to self: if I couldn't defend something as basic and obvious as this,
learn that I will never be able to defend any proposal.

Keep up the great work overall, sincerely

Have a beautiful day,

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_61ysHz%2BSR-kvHuw%2Bm8eN8r_b2FGx2LHuhDLpC5t37CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.contrib.auth CLI

2018-10-11 Thread Jamesie Pic
Sorry, I forgot to answer about the loaddata proposal.

So, loaddata will not do user removal for one thing.

About user creation, the process we have is:

- add the user to the users list,
- set the password in `ansible-vault create passwords/username`
- CM will execute createsuperuser for users,

>From that, it should maintain the userbase, on an ootb django project.

The workflow you are suggesting is:

- add the user to the users list,
- set the password in `ansible-vault create passwords/username`,
- somehow parse the settings to know the user model,
- generate a json file with the users, and hope that it will work with
their model,
- use a script that django doesn't have to generate a salted password,
- upload the script and apply it.

I don't think I want my automation steps to rely on hope.

What about the debugging process of such a complex implementation for such
a simple task ?
The cost is not worth the benefit. Injecting code in django-admin shell
still does the same with
a much cheaper complexity cost.

Have a great day.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19o1wUCd4CSvxHLKHAdBduPOO4H6PuhtuyZc_LYBO9ooA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.contrib.auth CLI

2018-10-11 Thread Jamesie Pic
Hi Adam,

Yeah it would be funny, maybe I'm even the only Django user that automates
deployments with a CM, or to take "ootb automation experience" up to that
point (maybe because I have extreme DevOps expertise ?).

Implementing this in a third party app is pointless: it will be more useful
as scripts in the CM role that will then work with any django project, as
I've been doing so far.

Because then my generic CM recipe can deploy any django project, without
"please install my app that will provide a working CLI for impotence and
user removal" (great security feature to have by the way). Yeah, it's
almost 2019, can Django learn about post-deployment task idempotence ?

Doing this in an external app is pointless, we'd be adding a manual step to
automate another one, i'm sorry but i can't do that, it doesn't make any
sense to me.

Also, that was explained in my initial email, sorry if it wasn't clear.

Best

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18N%3D37xwNRvB0dLJ2LDUbS2fPi_6jaYW7h_Q77%2B9ijF8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


django.contrib.auth CLI

2018-10-10 Thread Jamesie Pic
Hi all,

Currently, django has user management commands createsuperuser and
changepassword
,
which allow to automate some user management with an automated
Configuration Management (CM) tool, such as Ansible.

For example, you have a list of users in an a site-specific configuration
data repository, ie. of yaml files. You can program your CM can iterate on
it to create super users (example

).

The only issue is that it will choke when trying to create duplicates so
that's one thing I'd like to request comments about with the purpose of a
patch proposal to provide an idempotent command (example
). Another possibility to achieve
idempotence is to use another username list.

However what happens when a user leaves the team is that we add them to
another list, "remove_users" (example
).
Our CM will iterate over those, and delete the users. It would be easier
with a CLI command to drop a user /by login name/.

Yes of course we can stack some statements with semi colons, injecting code
into stdin of the django-admin shell command, and create a juicy one-liner.
I've been doing that for a while myself (some years), over again, so if
you're open to contributions I can direct some of that energy upstream
instead of in my own one-liners / deployment recipes.

I don't think this is a good candidate for being in an external app in my
opinion because the CM recipe should work with a Django fresh project, and
not require to install an extra app, hence the "containing it in a
one-liner".

Thanks for reading,

Have a great day

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_2iuRVFonCsYFhNZEfTfwfqEJB4PC0upjtYMzphvKXzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Model default modelform

2018-08-25 Thread Jamesie Pic
Hi Claude,

Thanks for your feedback, it's a great idea to make modelform a callable
registry instance or something.

In some project we're going to try to acheive this kind of coupling and
work with Python components instead of templates for example:

status = CharField(components=dict(form=MyStatusField, table=MyStatusCell,
card=MyStatusCard))

But this happens would happen in a router class, not directly in the model:
then you could remove Field.formfield() method.

Have a great day

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-CzyJLNddpW2xq6LhGseeqQG0PzukzoQodCvJ8d2PYTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Model default modelform

2018-08-24 Thread Jamesie Pic
Thank for your feedback.

It's the eternal misunderstanding of django's pattern, confusion between
table, and model, model is de factores what couples table and form, I've
posted articles about it already. I call this the elephant in the room but
if I'm the only one to see it it means it's my mistake.

Doesn't matter

Have a great day

Le lun. 20 août 2018 à 16:08, Adam Johnson  a écrit :

> Not sure that's what's being suggested here James?
>
> But I'm -1 on this because it's adding more coupling between models and
> forms.
>
> Also Jamesie, can't you just subclass in your ModelAdmin to
> replace get_form / View classes to replace get_form_class and achieve the
> same thing? As far as I understand the only thing your suggestion changes
> is that the forms used in views and admin can be changed at once, which is
> not necessarily desirable as both are intended for different users.
>
> On Mon, 20 Aug 2018 at 15:38, James Bennett  wrote:
>
>> I'd be -1 on anything that encourages people to use ModelForm with all
>> fields included by default; that's asking for mass-assignment security
>> holes.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAL13Cg--AGfXz4uLtAbC0miGCrQE9M1o6_cbC114UULBVhOPJg%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0wXj1%2B-jk61f-MHarZjMdXpYmPptxf4cC0SXZD1WvOqA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_GMvomL%3DjUjTmQdJhxm68hNqqdg-7a9DezcVSx42Y%2BDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Model default modelform

2018-08-20 Thread Jamesie Pic
Hi all,

Currently when you want a model to be edited from a custom modelform, you
need to make use of that new modelform manually in your create/update views
and admin.

Would it be possible to add a new overridable method in the model to
generate a default modelform ?

Then, default create/update views (including admin's) could detect if a
model has such a method and call it to get the modelform instead of going
through the default factory.

For example:

class YourModel(models.Model):
def get_form_class(self):
return YourModelForm

Thanks in advance for your feedback

Have a great day

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_e-065up%2Bs5mz7d%3D%3Dcxmz7w5coE0cMswfUpgOh3eRRjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


django.contrib.admin.models audit

2018-05-05 Thread Jamesie Pic
Hello everybody,

I have published a django.contrib.admin.models audit in a repository of mine
, that is like the admin
package but aspires to be useful also outside the admin:


   - uses a TextField for object_id
   

   which is not indexed, use an *indexed* CharField instead (to support
   ints and uuids),
   - upstream model does not have generic foreign key, so we don't have any
   of the querying features that would provide
   
,
   and has palliative code instead
   

   - status flags API is not extensible
   
,
   just make a setting and a default instead,
   - could have a better insertion helper
   
,
   for example, just take an object argument and figure out content_type,
   object_id and object_repr (with str(object)),
   - encapsulates a similarely non extensible change message
   
,
   not used by crudlfap which generates default overridable messages in the
   views

I'm posting this here because we are under no hurry to implement this on
our own, if you want we could implement this is Django itself rather than
in our own admin module.

Have a beautiful day

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18SPSrx1wCwnixG-nLz7n%3DcieC4C2Poq5iHoONZbjWL0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


django-adapters audit

2018-03-08 Thread Jamesie Pic
Hi all!

It’s been probably 30 hours I’ve spent trying to contribute to the
django-adapters
.
This article describes the approach we take when making investment audits
on software @ YourLabs as well as my conclusions on the django-adapters
project.

I started by reading what had been done and issues. My first mistake was to
not be patient enough to really read and profoundly understand absolutely
every piece that had been done.

It seems to me that what django-adapters tries to do is invent a new
pattern to solve the kind of problems we usually deal with as developers:

   - fetch data from some source, using various python libraries for
   example, converting settings into things like API urls and whatnot,
   - make a friendly data submission interface striving to help the user
   fix his data input until valid, the more friendly it is, the less Humans
   will be waiting for our answers on how exactly it is usable,
   - process the valid data which means executing various steps, from
   writing a file to sending an email or triggering a channels job, and
   outputing something, an json dump, an html body, a response object, or
   something

In 2018, we also need to write good JS code, having good development
workflows like JS or Python developers have surely help. For DRY purposes,
we need to be able to pick up on the client side where the server side left
the story.

Example: If something should add or remove a field, we should only specify
it once, then be able to code both the client and server, in different
languages ok that works for me: code the server in python, client in js,
because it’s not an isomorphic Go or Node project, but as a Human being my
issue is the same. This is why i started the facond project

with a reasonable ambition that fits my little size. python-adapters
however, should enable as a framework to glue different libraries around
data they can share logic on, dump/restore the logic schemas, and be
introspectable and mutable to enable even more in-the-foot-shooting.

Surely, this will create a lot of new problems, but will fix a lot of
problems we have been having for the past 10 years. Is this going to fix
more problems than it will solve ? Given the frustration around several
components which are just too old, but kept for backward compatibility.

*And python-adapters have a great pattern to make things compatible so
that’s absolutely complementary, adding adapters to an existing project can
only enhance it.*

Now, for the financial part of the report.

Where’s dealing with a beast size piece of software, this can be a
framework on its own, to actually glue all apps in the python ecosystem
together, based on steps being executed on payloads and mutable data
structures with a certain isomorphism, and with django bring that to a high
level, so in my opinion to can have a ROI of a million USD/year starting
next year, if really this is produced by the team of people watching this
repository.

I think a time estimate of 300 man hours will be a minimum, but if we want
this to be as perfect as we can we know how 300 hours can slip into 500, so
for security, YourLabs Business Service recommendation is to start the
project with 50k, as sponsor we’ll provide a major part of that budget.

That said, I still think most of it is not django specific, so we could
target the whole python community, should be python-adapters rather than
django-adapters: this is a framework for gluing code, it can help with a
web framework, but is also useful without web frameworks.

I also recommend that we do not close our eyes on tech debt in our JS code,
and aim for the same testability and coverage than with our python code. Of
course, the JS lib will also be usable without Python, or with any server
side language, as long as they can dump their adapter tree in JSON like the
Python reference version.
https://blog.yourlabs.org/post/171663429858/django-adapters-audit-writeup

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: DEP Pre-posal: Re-Designing Django Forms

2018-02-03 Thread Jamesie Pic
On Thu, Feb 1, 2018 at 12:46 PM, Marc Tamlyn  wrote:
> This is a huge project to achieve everything you mentioned in your email,
and it has implications across a large number of Django packages (not least
the admin). I don't want to discourage you, but don't underestimate how
much work it would be to get a good replacement for forms for the modern
web.

Perhaps we should just be able to swap Forms with WTForms or another python
library and bake in ElementUI, even if that means replacing template_name
with vue_name in the view generic class, but if we're talking about "modern
web" then perhaps it's time for npm to become a first class citizen.

> Your next steps should be to research, spec and potentially write a DEP.

In my recent research it seemed ElementUI the most feature complete UI. It
includes ajax file upload which every user expects in the modern web which
seems to be the feature which defines feature-completion of a UI framework,
compared to what HTML offers out of the box.

Thanks a lot for doing something about this Robert, forms in django
definitely needs a major refactoring sprint, typically remove the
field/widget layer and rely on one level inheritance that will help a lot
for example with material design which displays field.name inside the
widget, not possible with current object design.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Form.factory

2017-12-18 Thread Jamesie Pic
Hello everybody,

Currently, we can set extra request/view arguments in a form by overriding
a CBV get_form* method. This way, we can add things such as request.user,
if we also override the Form constructor to accept such arguments.

I'd like to suggest that we add a factory(cls, view) method to the Form
class, and make CBV call self.form_class.factory(view, *ctor_args,
**ctor_kwargs) as a way to keep the view->form variables logic in a single
place.

Thanks for your time
Best regards
<3

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_OFL6vOGH-PxXmx4zNkUxQMFhEN7Ded4e1zYhL50QEyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vendoring Select2

2017-12-16 Thread Jamesie Pic
Note that jquery-autocomplete could be a backup solution in case select2
looses maintainer traction in the future.
​
https://www.devbridge.com/sourcery/components/jquery-autocomplete/

Best
<3

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op190kX1ugAWifVw4h2GPRZ6DoHgwy9nkhPAUBmSWGhudpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django benchmark is low

2017-12-16 Thread Jamesie Pic
Well, they're using tornado as frontend serveur, perhaps they should try
with uwsgi.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-5D3WcGK8jqZj7QeSikxsh7cWUNFN2EvXF%3DfDORef5FQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extract LogEntry from django.contrib.admin

2017-11-08 Thread Jamesie Pic
I'm sure we can have many interresting features:

- admin page to view logged requests/responses with replay feature
- admin page to view logentries per object,
- add level/source and support being a python logging handler

Perhaps more ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_0rkiDPGfM9jLcD5HBWEz4P%2Bx6ff1RDTw2cWnXrG4aVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Extract LogEntry from django.contrib.admin

2017-11-07 Thread Jamesie Pic
Hello

Have we considered extracting LogEntry from django.contrib.admin in its own
contrib module ?

It would open doors for new features such as automatic request/response
trace & exceptions loggers and views in the admin perhaps ?

<3

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19dzcESDgBRtt6Se81_00nfWHu8j7vKpi88EPe_qu68ig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: New Permissions Scheme

2017-09-22 Thread Jamesie Pic
Have you tried of django-guardian ? What do you think about it ?

TBH I never actually used it (I've been doing Django for 9 years and have
never used a permission table), but I think it does what you want.

>From my experience, permissions are thought of something that can be
calculated on the fly, and that's always been the shortest path. The only
thing is, that you *should* then setup your base queryset per-model
per-user OOAO, and then setup permissions per view.

Also, I don't understand how to make DRY code with the permission system:
check a permission to display or not a link in the template, and also
duplicate this check in the view's dispatch or something.

Nowadays, I prefer to set View.allow to a function I re-use, and call it in
dispatch exactly like jinja templates and have a queryset generator that
takes a user argument that all views in a given url router will use by
default: List, Delete, Update, and so on, rather than maintaining
boilerplate code to maintain a database table when something else changes
in the database.

While I can understand how you could need django-guardian in some projects,
I can understand why you want security as a feature in any project ;)

Keep up the great research !
<3

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19xnSfM7KbJryJE5kYnY5BeSZ4tx8G5f3CvXEo0EU335Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Why Django Document site always redirect to an earlier version

2017-09-22 Thread Jamesie Pic
Amazing, what's the output when you try `curl -I
https://docs.djangoproject.com/en/stable/ | grep Location` ?

If none, try without the `| grep Location`.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19udqGVitzwK%2BURw7cYo-h4oayLcpWHUTDsey3yGbz7pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Decoupling Forms from Model

2017-09-18 Thread Jamesie Pic
Thanks Tim, I had completely forgotten about this episode.

I've given up the idea of changing this (amongst other things) in Django
and decided to work a layer on top of Django instead (
https://github.com/yourlabs/crudlfap ).

As far as I'm concerned, we can close this.

Thanks a heap for answering,
Have a great day.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-WwMhxPrT8HYE40Ub1-9u0vRdQcE_HzhmNn-FFoEXzFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Decoupling Forms from Model

2017-09-17 Thread Jamesie Pic
Hello everybody !

Currently, it's possible to override a model field to override the
formfield method. This allows to generate a default form from a model with
the ModelForm. This is something that other maintainers of small django
apps providing with new form fields might also have seem users struggling
with on GitHub or StackOverflow.

In Ponzu framework, they register a function for a model type which returns
a form object. Example MarshalEditor function for their Song model in a
Ponzu Example:
https://github.com/ponzu-cms/examples/blob/master/news/examples/createable/content/song.go#L25

If Django had something similar then there would be no need for model
Field.formfield anymore. Also, users would have more freedom to design how
they want their default model forms to look like.

Thanks in advance for sharing some of your insight.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1-N%2BOJf2nefTpJ0s1aPfNLVPeRr%2Bo1MmTMVN1NDEHyiAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vendoring Select2

2017-06-18 Thread Jamesie Pic
Awesome, hope this will help drag in maintainer activity on select2 <3

Best

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_P-cvdqT_XeTGPrsuRSXN%3DRS3aF_MokofVVS_eF12_JA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vendoring Select2

2017-06-06 Thread Jamesie Pic
I was just thinking that changing the js widget would not require to
rewrite the python code, barely the js widget support. I'm not trying
to push it, just make sure we are taking the right facts into
consideration, but I'm happy with select2 myself.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19phT4US3Un0uQP3_2nnqzM7msizV7LfzBEYfizNqYdtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Vendoring Select2

2017-06-06 Thread Jamesie Pic
Thanks for asking, my name is ∞, but you've known my as James Pic /
YourLabs. Nice to speak with you again <3

I think it would make sense for a core dev to advocate against this
change, because we'd be breaking BC before having enough information
to know if this is going to have a generally more positive than
negative impact, I wouldn't be able to tell without trying it myself
with a community for a couple of years, and have the opportunity to
try it out with a bunch of app/widget combinations, because the Django
ecosystem (at least, the part I rely on and love) is so huge :D

Best
<3

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_AjF8xMnbi7ym8Ceu45oDeiR8woaN-0K_4PZmzYT0CrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: #26369: default formfield callback override

2017-04-17 Thread Jamesie Pic
Hi David,

Yep, I'm with you on this, another good reason to close this PR. I'm
building DAL's next feature on your fork, so you'll have my feedback
for sure at some point ;)

Best
<3

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18XCRC3Kj328OX0-0UqPMtwkQtu7O3p88Kgc%3De%3DGEHcdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: #26369: default formfield callback override

2017-04-16 Thread Jamesie Pic
Ooops yes this is correct, it doesn't work in the advised file, apps.py

Thank you so much for your feedback, I need to ditch this patch just
find a way to make Django default usable date, time, image, relations
form fields useable ootb by marrying a JS framework.

Best
<3

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op19jtK2EphhyeLL0NqBVg3JZ%3D%2Bbg8BScS9VwUVusx9Jh0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: DJANGO_SETTINGS_FILE

2017-04-14 Thread Jamesie Pic
If this is about making deployment easier, then it might take long
before anybody contributes windows support.

After inheriting from the projects settings "from myproject.settings
import *", I have not experienced the caveats.

Something as simple as overriding a settings file as never been
easier, as it should be.

I recommend that you try Adam's package even if you never use
configuration files per deployment.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_K4W7yB2he02QrP%2B4jTdub_sA8uXG1UrFk5UjRK7QtkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.