Re: Overriding template blocks without copy/pasting entire template files

[Arvind Nedumaran]

Could you elaborate on how this is different from extending a base template
and re-defining the necessary blocks?

#base.html
{% block title %}{{ section.title }}{% endblock %}
.

{% extends "base.html" %}{% block title %} My custom title that isn't
section.title {% endblock %}


This much is already possible right?


On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton 
wrote:

> Something that has bugged me for awhile is the requirement to copy and
> paste an entire template when you would just like to override a single
> block. This arises mostly when overriding admin templates, like
> `admin/base.html`.
>
> In my ideal world, I'd be able to do something like this:
>
> # myapp/templates/admin/base.html
> {% override "admin/base.html" %}
> {% block footer %}this site is restricted, blah blah legal text blah{%
> endblock %}
>
>
> And then the template loading system would find the next `admin/base.html`
> in the chain and use my overrides.
>
> There is prior art too. https://pypi.org/project/django-apptemplates/
> allows you to override a template from a specific app using this syntax:
>
> # myapp/templates/admin/base.html
> {% extends "admin:admin/base.html" %}
> {% block footer %}this site is restricted, blah blah legal text blah{%
>  endblock %}
>
>
> I think this kind of functionality should be included within Django
> itself. If others agree, should there be a new name such as override, or
> would overloading extends be good enough?
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAF_6RoMTbiq4S9qFBL1qU4B_KcJU%3DveP2%3D%2BMaT0%3D1Uxee%2BiEAQ%40mail.gmail.com.

Re: Overriding template blocks without copy/pasting entire template files

[Arvind Nedumaran]

Something must be faulty with my email delivery I suppose. I sent that email a 
good 8 hours ago. :)

Onward,
Arvind

Sent from Outlook Mobile<https://aka.ms/blhgte>


From: django-developers@googlegroups.com  
on behalf of Florian Apolloner 
Sent: Tuesday, June 16, 2020 6:46:45 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Overriding template blocks without copy/pasting entire template 
files

If you look at the mails beyond the first one, you will see that Josh & Carlton 
already came to that conlusion ;)

On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote:
Could you elaborate on how this is different from extending a base template and 
re-defining the necessary blocks?

#base.html
{% block title %}{{ section.title }}{% endblock %}
.

{% extends "base.html" %}
{% block title %} My custom title that isn't section.title {% endblock %}


This much is already possible right?


On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton  wrote:
Something that has bugged me for awhile is the requirement to copy and paste an 
entire template when you would just like to override a single block. This 
arises mostly when overriding admin templates, like `admin/base.html`.

In my ideal world, I'd be able to do something like this:

# myapp/templates/admin/base.html
{% override "admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


And then the template loading system would find the next `admin/base.html` in 
the chain and use my overrides.

There is prior art too. https://pypi.org/project/django-apptemplates/ allows 
you to override a template from a specific app using this syntax:

# myapp/templates/admin/base.html
{% extends "admin:admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


I think this kind of functionality should be included within Django itself. If 
others agree, should there be a new name such as override, or would overloading 
extends be good enough?

--
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-d...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB2918A6E0935FE4DABCD96991A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: The blacklist / master issue

[Arvind Nedumaran]

The "default" is name is just a convention. It can be other things and after a 
few days of "teething" issues, and everyone will be back to being as productive 
as they are right now.

Sent from Outlook Mobile


From: django-developers@googlegroups.com  
on behalf of אורי 
Sent: Tuesday, June 16, 2020 7:05:19 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: The blacklist / master issue

I think master is the default branch name in any Git repository. It's not about 
Django and even not GitHub. Do you want to change the default branch name in 
Git?
אורי
u...@speedy.net


On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick 
mailto:t...@carrick.eu>> wrote:
This ticket was closed 
wontfix as requiring a 
discussion here.

David Smith mentioned this Tox 
issue stating it had been closed, 
but to me it seems like it hasn't been closed (maybe there's something I can't 
see) and apparently a PR would be accepted to add aliases at the least (this is 
more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet 
article
 - it seems like Google have already made moves in this direction and GitHub is 
also planning to. Usually Django is somewhere near the front for these types of 
changes.

I'm leaning towards renaming the master branch and wherever else we use that 
terminology, but I'm less sure about black/whitelist, though right now it seems 
more positive than negative. Most arguments against use some kind of 
etymological argument, but I don't think debates about historical terms are as 
interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms 
somewhat reluctantly. I do think Luke is correct that we should be concerned 
with our credibility if we wrongly change this, but I'm also worried about our 
credibility if we don't.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.com.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeH3ixuxTqBvB6FdLzimDbB4D5uGHKEawwjvqXVHU%3DcvKg%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB2918D1D9008D787BC2AF1F95A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: Overriding template blocks without copy/pasting entire template files

[Arvind Nedumaran]

No worries 👍

Sent from Outlook Mobile<https://aka.ms/blhgte>


From: django-developers@googlegroups.com  
on behalf of Florian Apolloner 
Sent: Tuesday, June 16, 2020 7:40:56 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Overriding template blocks without copy/pasting entire template 
files

Ah, might be that you got hold up in a moderation queue or similar. Google 
groups is weird sometimes -- sorry!

On Tuesday, June 16, 2020 at 3:20:25 PM UTC+2, Arvind Nedumaran wrote:
Something must be faulty with my email delivery I suppose. I sent that email a 
good 8 hours ago. :)

Onward,
Arvind

Sent from Outlook Mobile<https://aka.ms/blhgte>


From: django-d...@googlegroups.com  on behalf of 
Florian Apolloner 
Sent: Tuesday, June 16, 2020 6:46:45 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Overriding template blocks without copy/pasting entire template 
files

If you look at the mails beyond the first one, you will see that Josh & Carlton 
already came to that conlusion ;)

On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote:
Could you elaborate on how this is different from extending a base template and 
re-defining the necessary blocks?

#base.html
{% block title %}{{ section.title }}{% endblock %}
.

{% extends "base.html" %}
{% block title %} My custom title that isn't section.title {% endblock %}


This much is already possible right?


On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton  wrote:
Something that has bugged me for awhile is the requirement to copy and paste an 
entire template when you would just like to override a single block. This 
arises mostly when overriding admin templates, like `admin/base.html`.

In my ideal world, I'd be able to do something like this:

# myapp/templates/admin/base.html
{% override "admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


And then the template loading system would find the next `admin/base.html` in 
the chain and use my overrides.

There is prior art too. https://pypi.org/project/django-apptemplates/ allows 
you to override a template from a specific app using this syntax:

# myapp/templates/admin/base.html
{% extends "admin:admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


I think this kind of functionality should be included within Django itself. If 
others agree, should there be a new name such as override, or would overloading 
extends be good enough?

--
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-d...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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-d...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a357fb57-55b3-4f65-bf59-cf64c3e412bbo%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/a357fb57-55b3-4f65-bf59-cf64c3e412bbo%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB291880739C1BB3E52F821C18A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.

Welcome email

[Arvind Nedumaran]

Hey everyone,

I notice that people who try to find support on using Django mistakenly post in 
this list and sometime usually has to write an explanation about how this is 
the wrong place.

Could we possibly as a welcome email whenever someone joins the group?

Just a suggestion.

Best,
Arvind

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB29181EBF50C845052F69E5E1A3680%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: Welcome email

[Arvind Nedumaran]

Oh I understand. I meant we could include the distinction in the welcome email 
and possibly a link to the other list.

That may reduce the number of people who may be looking for help but end up 
here mistakenly?

Get Outlook for Android<https://aka.ms/ghei36>


From: django-developers@googlegroups.com  
on behalf of אורי 
Sent: Sunday, July 5, 2020 8:39:22 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Welcome email

I think because this list is called Django developers and what we call "Django 
users" are also developers who use Django. But they are developers.

אורי
u...@speedy.net<mailto:u...@speedy.net>


On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran 
mailto:arvindamir...@gmail.com>> wrote:
Hey everyone,

I notice that people who try to find support on using Django mistakenly post in 
this list and sometime usually has to write an explanation about how this is 
the wrong place.

Could we possibly as a welcome email whenever someone joins the group?

Just a suggestion.

Best,
Arvind

--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB29181EBF50C845052F69E5E1A3680%40BYAPR14MB2918.namprd14.prod.outlook.com<https://groups.google.com/d/msgid/django-developers/BYAPR14MB29181EBF50C845052F69E5E1A3680%40BYAPR14MB2918.namprd14.prod.outlook.com?utm_medium=email&utm_source=footer>.

--
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<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeH0WySFuBnzyXENnMt-5bN5hawS4HYoNUVeGFG8TLG0qw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CABD5YeH0WySFuBnzyXENnMt-5bN5hawS4HYoNUVeGFG8TLG0qw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB291816DB21661EDBBC954AB5A3680%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: Resume app designing need help

[Arvind Nedumaran]

Hi,

You have reached the mailing list for discussing the development of the Django 
framework.

I think you're looking for help with using Django which is a different mailing 
list (django-users). Or check out the forum at forum.djangoproject.com

Best,
Arvind

Get Outlook for Android


From: django-developers@googlegroups.com  
on behalf of Kranthi Kotagiri 
Sent: Thursday, July 9, 2020 9:53:02 AM
To: Django developers (Contributions to Django itself) 

Subject: Resume app designing need help

I'm a student in the USA. I want help to complete the assignment I was really 
in trouble in the deadline. I need really less time from you. I attach my 
project source code if you run the code in vs studio you get and template. and 
I attach the other resume file. Can Someone help me with this?
I want the working_resume app to change like a resume-full stack. Changing only 
the template.

Please help me!
Thank you

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/874dd3c5-e004-4727-bb54-0e7e5e2967cdo%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB29182FD1D3664F71E9E0A2DFA3640%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: Adding a security concerned feature

[Arvind Nedumaran]

The one I follow is to set an environment variable to see if it’s a 
public facing instance or a private one (disconnected from the internet) 
and use that as a condition, which when true will add some urls.


It’s the same pattern you’ll follow when using something like Django 
debug toolbar - where you check if debug is true and if it is, you add 
some more urls to the root urlconf conf.


Hope that helps.

P.s. This is the mailing list for contributions to Django itself. 
Questions about how to use django are better suited in the Django Users 
mailing list or the forums.


Onward,
Arvind


On 10 Nov 2020, at 14:46, Shoury Sharma wrote:


Hello everyone!
I was going though idea of admin page but sometimes it can be a 
security

concern regarding access of admin stuff by URL/admin.
I would therefore like to give a suggestions regarding the URL/admin 
to be
some key which only the owners would have access to so the user can 
never
have anyway to check admin by penetrating into it in any malicious 
way.

Generous regards,
Shoury Sharma

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/46bf01ff-dc32-47ff-92bc-c56c260a9f29n%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10669A3E-5DBB-46C8-8CF3-411C7DC149CC%40gmail.com.

Re: Adding a security concerned feature

[Arvind Nedumaran]

A security model doesn’t necessarily have to be any one thing that’s 
100% secure. It can be a combination of things which include 
“actual” security features as well as plain ol’ obscurity.


If I have to register the admin urls on a project, I make sure to setup 
django-honeypot and move the admin site to something non-standard.


Any one thing may not be doing much on it’s own. But the combination, 
if messy enough to make someone give up, will give you a better overall 
security situation.


Just my 2¢.

Onward,
Arvind

On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:


FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
compelling argument for recommending developers to change the default
"/admin" url.  Any security concerns would hopefully be addressed by 
actual
security safeguards rather than changing names to something 
non-standard.


On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 
carlton...@gmail.com

wrote:


On this topic, a ticket proposing to prepend the project name to the
`admin/` URL in the default project template was opened.
https://code.djangoproject.com/ticket/32209

Given that it's the exact discussion we're having here, I've paused 
that

to see if there's a consensus for a change.

Thanks. C.

On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com 
wrote:


 I've got this idea with the usage of json files that require some 
keys
which is authenticated for a single user which seems to excite me 
for fact
that if this was similar for admin/, then it'd give django a 
overhead

advantages for future use.

On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
wrote:


I think I'd come down as -1 for a system check here...

They're not costless, there's a tendency to want to add a new 
system
check for every possible configuration choice, but, beyond 
implementing and

maintaining, the danger is it leads to too much noise.
If you get a system check warning, you shouldn't be tempted to 
ignore
it. In general I think reserving the built-in checks slightly means 
they
don't get devalued. (Folks are free, and encouraged, to implement, 
and

share, their own checks to enforce project-level standards.)

I think it's not sufficiently clear-cut that using `/admin/` is a 
bad

idea to justify including a check.

(On a personal note, I like to use `/admin/`, configure nginx to 
only
serve the admin from the localhost, and then use an SSH tunnel to 
access it

remotely, so I'd have to silence a system check here.)

C.

On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany
wrote:



Hi,

I wasn't convinced about changing the 'admin' path until recently. 
My

reasons to change the path of 'admin' are:

-A bit less likely to be affected by bugs like

https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
: at least the site wouldn't appear in automatic scans for
vulnerabilities (if checking Django versions based on the admin
template, etc.) . The bug/exploit might have been known before the 
fix
was implemented (and everyone updated) so I prefer to not be 
exposed

(or
less exposed)

-At the moment in Django there is no rate-limiting login attempts 
"out

of the box" so I prefer to avoid the opportunity if possible

-Partially out of my control: an 'admin' user might have used the 
same

password in another place and the password got leaked

Other people might have other reasons.

Cheers,

On Nov/18/2020, Tim Graham wrote:
I'm not convinced that a system check promoting security by 
obscurity

adds
much value. The original poster wrote "sometimes it can be a 
security
concern." Maybe that's the case (how so?) but for most sites I 
would

say

it's not.
On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina

Estany

wrote:



Hi,

On Nov/16/2020, Carles Pina i Estany wrote:


Either way: I'd be happy to write a django check to make sure

that

'admin/' is not routed to admin.


Regarding this check: this morning I've done a very 
preliminary/for

fun

draft to play with.




https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1


I'm not sure what is the best way to check if /admin is routed 
to

django.contrib.admin. At the moment it's doing:

resolve(admin_url)._func_path == 
'django.contrib.admin.sites.index'


Yes, I know! :-)

I could also do something along the lines of:
resolve(admin_url).func.admin_site == admin.site

This causes problems on the unit test side (need to import

admin.site).

Still I don't really like it.

Does anyone have any better suggestions or comments? (or code

pointer).

Otherwise later on I'll have another look.

Thank you very much,

--
Carles Pina i Estany
https://carles.pina.cat



--
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-develop...@googlegroup

Re: Model Generation for CSV, XLS Files

[Arvind Nedumaran]

Hi Muskan,

There isn’t anything that directly lets you load a CSV and generate 
models for it as far as I know (I may be wrong).


But check out the Django documentation’s HOWTO on integrating with 
legacy databases - 
https://docs.djangoproject.com/en/3.1/howto/legacy-databases/.


One possible solution for what you’re trying to do may be imagined as 
a flag for the ‘inspectdb’ command that lets you pass a CSV file? 
Just a thought.


Good luck with GSOC.

Onward,
Arvind

On 26 Nov 2020, at 0:30, Muskan Vaswan wrote:


Hi everyone,
I am Muskan and am very new to this community however not that new to
django itself. Contributing to django is something I would really like 
to

do, and I might also be participating in GSoc for the same.

I have an vague idea of what I want to fix, because I myself have used
django and just want to add things as a developer that I would've 
wanted as
a user. So my question is understanding based around this idea of 
mine.


*I want to know what functionality already exists that makes it easier 
to
directly load a large data set into a django model from a CSV file 
(going
with the simplest format or now).* When I had to do it as a user it 
took me
quite a while and was a lot more complicated than I had expected, 
after

being used to smooth transitions with load data. I could not find any
better methods to do it, if there indeed exists no other methods, this 
is

something I would like to work on So this is just to confirm if my
research was thorough enough (very possibly wasn't).

Thank you! I'm excited to begin helping out!

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a3946181-cd91-4b83-b9d6-d8d8f786b6acn%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/158EA79E-91F4-4A65-83BD-73B5F81E94B8%40gmail.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[Arvind Nedumaran]

A case could be made along the same lines as was made for South.

Get Outlook for Android


From: django-developers@googlegroups.com  
on behalf of Mariusz Felisiak 
Sent: Tuesday, December 15, 2020 9:58:56 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Replace the default django test runner to a more robust testing 
framework (like pytest)

Hi,

I agree with René and Adam, pytest and pytest-django already exist, and I 
don't see why we should copy it to Django or change the default test runner.

Best,
Mariusz


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/60a4a090-8ff5-477e-9651-db1fbf5c397bn%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BYAPR14MB29187430911979D1A75E7E62A3C60%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: collectstatic command should output minified files

[Arvind Nedumaran]

I kinda like the idea of being able to run collectstatic and not have to 
worry about setting up a full on frontend workflow for pretty much just 
minification. It is a great default to have when this is all you need.


That said, I’d be more interested in seeing something like an official 
or a django-blessed unofficial default option similar to the 
sprokects-rails gem for ruby. Allowing for a much more flexible and 
extensive frontend pipeline without having to rely on an external task 
runner.


On 22 Dec 2020, at 7:24, Diptesh Choudhuri wrote:


The default files copied to STATIC_ROOT when you run python manage.py
collectstatic should have two versions- file.js and file.min.js 
(similarly
for css files). As far as I can see, this happens only for the 
preinstalled

apps (like admin/actions.min.js) but not for user installed apps.
Serbing minified static files is important for all production 
environments
for pretty much everyone who uses vanilla django. Though there are 
packages

out there to do this, I feel it is important enough and has enough use
cases to be added to the django core.

I can start working on this if it is accepted.
Let me know what you think!

Best
Diptesh Choudhuri

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5bcb1522-3486-452e-b061-2cce2bb6d2c9n%40googlegroups.com.


--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/276A5D36-D8EE-41A7-9C64-16A3B167FD7B%40gmail.com.

Re: collectstatic command should output minified files

[Arvind Nedumaran]

I didn't mean we should include things in Django. Even a workflow that 
integrates with Django using manage.py commands will be super useful.

Right now, I use Parcel + Tailwind (csspostprocessor mostly) + done JavaScript. 
It's supposed to be simple.

Even for this, I need to run to terminals (one for Django, one for the 
frontend) or use something like Honcho with a procfile just so I can develop in 
peace. Or I should hack gulp to run Django runserver for me.

This is not documented anywhere officially but is a very very common workflow 
even for small applications.

I'm saying we do something to make this an easier process.

Get Outlook for Android


From: django-developers@googlegroups.com  
on behalf of Dmitriy Sintsov 
Sent: Tuesday, December 22, 2020 3:59:15 PM
To: django-developers@googlegroups.com 
Subject: Re: collectstatic command should output minified files

There is one trouble: Webpack assumes it's own subtree of assets to process, 
while Django loads assets from packages (Django apps) directories. I still 
haven't seen a successful setup of webpack which would respect loading assets 
from Django packages directories.
Another trouble, not everyone wants to carry node.js subsystem with it's huge 
list of packages in their Python / Django project.
But there are changes that transpiling would not be required in the future at 
all, after IE11 would fade to the past:
https://www.freecodecamp.org/news/you-might-not-need-to-transpile-your-javascript-4d5e0a438ca/

On Tue, Dec 22, 2020 at 1:20 PM Adam Johnson 
mailto:m...@adamj.eu>> wrote:
django-compressor is also popular: https://pypi.org/project/django-compressor/

IMO we should not include anything in Django since JavaScript is a separate 
language, and they have much better tools for minification and bundling, and 
these tools can move faster than and orthogonally to Django. And there are many 
options: Webpack, Parcel, Gulp, Grunt, Rollup, ..

On Tue, 22 Dec 2020 at 10:06, quest...@gmail.com 
mailto:questpc...@gmail.com>> wrote:
There is CSS / Javascript merge and compress package for Python:
https://github.com/miracle2k/webassets
which supports Django, Flask, Pyramid.

See also:
https://www.slideshare.net/__amol__/pyconit7-dukpy-webassets-free-yourself-from-nodejs-chains
https://pypi.org/project/dukpy/
https://gist.github.com/amol-/0fd016bbb0c6c9a0fb6ab5bbedfcb7ad
https://github.com/rclmenezes/webassets-rollup


On Tuesday, December 22, 2020 at 5:03:54 AM UTC+3 
arvind...@gmail.com wrote:

I kinda like the idea of being able to run collectstatic and not have to worry 
about setting up a full on frontend workflow for pretty much just minification. 
It is a great default to have when this is all you need.

That said, I’d be more interested in seeing something like an official or a 
django-blessed unofficial default option similar to the sprokects-rails gem for 
ruby. Allowing for a much more flexible and extensive frontend pipeline without 
having to rely on an external task runner.

On 22 Dec 2020, at 7:24, Diptesh Choudhuri wrote:

The default files copied to STATIC_ROOT when you run python manage.py 
collectstatic should have two versions- file.js and file.min.js (similarly for 
css files). As far as I can see, this happens only for the preinstalled apps 
(like admin/actions.min.js) but not for user installed apps.
Serbing minified static files is important for all production environments for 
pretty much everyone who uses vanilla django. Though there are packages out 
there to do this, I feel it is important enough and has enough use cases to be 
added to the django core.

I can start working on this if it is accepted.
Let me know what you think!

Best
Diptesh Choudhuri

--
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-develop...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5bcb1522-3486-452e-b061-2cce2bb6d2c9n%40googlegroups.com.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b4ee304c-6861-417c-a20c-bf79b5e2d9efn%40googlegroups.com.


--