Re: django-admin startproject settings.py has some security holes

[Nick Sarbicki]

I strongly disagree with this.

I've not seen a common standard between companies when it comes to settings
in Django and for good reason. Different companies employ different
standards and practices when it comes to configuration and security.
Enforcing an arbitrary standard - such as a settings file for each env - is
too opinionated for me and would often involve extra work on setup to
remove this initial way of doing things.

Likewise in my experience ignoring settings files is actually quite rare.
Most companies store secrets external to the settings file and prefer to
keep their settings in git. Adding a .gitignore with the settings files
would actually cause issues on future projects where you aren't expecting
this.

As mentioned this isn't necessarily to say having multiple settings files
or ignoring settings files are bad in an individual project. But that every
project has its own way of handling configuration and secrets, so enforcing
the standard *you* follow on everyone else - not because it is the best
possible way of doing things, but because it is how you do things - is
unlikely to be a popular move.

Adapting your settings configuration to the way you work is a small amount
of work - Django does a good job at the moment of staying unopinionated on
this whilst giving you what you need to get going.

On the SECRET_KEY. It is true that many people commit their SECRET_KEY into
the repo. But in the same way that you often get people committing DB
credentials and API keys. It is not a frameworks job to inform you of every
security malpractice (although Django does a good job of this already), it
is up to the developer to understand what they are doing. Despite this
there is extensive documentation on the SECRET_KEY needing to be secret,
mentioned both in the settings documentation and the deployment checklist.
There is even a comment above this setting explicitly stating that it
should be kept secret in production.

Assuming Django's startproject command aims to have a fully functioning
project from the get go - which means it needs a SECRET_KEY - then I think
this is a pretty good compromise as is.

- Nick


On Fri, Oct 11, 2019 at 12:14 PM Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi, may I disagree - I set up projects very often (for testing a package),
> and I always feel a bit awkward because of that monolithic settings.py file.
>
> I can really support Bobby's idea, even if development/staging/production
> may be a bit overkill. Having a practical standard which ensures good
> practice from the start is a good thing. And OTOH, it won't hurt anyone if
> these files are there.
>
> As there was another discussion earlier about "declarative" settings -
> maybe it would be helpful to exclude some of the settings from settings.py
> which is code, not declaration. SECRET_KEY could be anywhere by default, it
> doesn't have to be in an executable .py file. But this would mean to change
> Django's code to read it before or after importing settings.py.
>
> +1 for a .gitignore file too.
>
> Christian
> Am 10.10.19 um 22:18 schrieb Ehigie Aito:
>
> Hello Bobby,
> I think this should be added to a best practises documentation and not
> codified in Django. As I feel that would be overkill.
>
> On Thu, 10 Oct 2019, 20:41 Bobby Mozumder,  wrote:
>
>> In particular, they include settings that shouldn’t be stored in a git
>> repo such as SECRET_KEY and database passwords. You’ll find these kinds of
>> settings in git repos all the time.
>>
>> Really the default django-admin startproject shouldn’t have a single
>> settings.py that people include in their git repos, but instead a python
>> settings module, with a base.py, development.py, staging.py, and
>> production.py. An __init__.py reads base.py and one of
>> development/staging/production based on ENV variables (defaulting to
>> development if no ENV variable).
>>
>> Additionally, startproject should add a .gitignore in the root directory
>> to not include development/staging/production settings files.
>>
>> I get that this might not be absolutely necessary but I think these are
>> the kinds of defaults that make practical real-world use more secure, as
>> well as standardizing workflow for more advanced production usage.
>>
>> Is this something agreeable? I can put together a solution if people like
>> this.
>>
>> -bobby
>>
>>
>> --
>> 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/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.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 

Re: Explore integrating django-docker-box in some way?

[Nick Sarbicki]

That makes sense.

Do we have a list of the versions required? I'm happy to try it out and see
if it makes a difference.

- Nick


On Tue, Oct 8, 2019 at 12:05 PM Tom Forbes  wrote:

> I did experiment with it. The main problem is that the image we use
> requires a bunch of system libraries (see
> https://github.com/django/django-docker-box/blob/master/Dockerfile#L4). I
> think a few where missing our outdated in Alpine, but if that's changed
> then I'm not against trying it again.
>
> Tom
>
> On 8 Oct 2019, at 11:58, Nick Sarbicki  wrote:
>
> Just out of interest, Tom, have you tried using Alpine as the base? Or is
> there a reason to avoid it?
>
> I usually find once you introduce all the dependencies for django it
> doesn't make a huge difference but it might shave some of the weight off if
> we're worried about image size.
>
>
> - Nick
>
>
> On Tue, Oct 8, 2019 at 11:52 AM Josh Smeaton 
> wrote:
>
>> I was going to archive the repo, but it seems I don't have the necessary
>> permissions. Carlton, do you?
>>
>> On Tuesday, 8 October 2019 21:45:22 UTC+11, Adam Johnson wrote:
>>>
>>> +1 to archiving django-box
>>>
>>> On Tue, 8 Oct 2019 at 11:01, Tom Forbes  wrote:
>>>
>>>> Thank you for the kind words Bruno! I'm glad it's helped you, if you
>>>> have any suggestions for improvements then please open an issue on the repo
>>>> or post a message here, I know it's not perfect. I would have replied
>>>> earlier but this message didn't get delivered to me.
>>>>
>>>> I'm biased, but I'd be +1 on archiving the old django-box. It's served
>>>> us well, but unless someone is willing to spend some time updating it then
>>>> it's going to confuse new users.
>>>>
>>>> On Friday, 4 October 2019 12:40:02 UTC+1, Bruno Alla wrote:
>>>>>
>>>>> Just a note that as a newish contributor to Django, this
>>>>> django-docker-box is fantastic, it makes things much easier to setup.
>>>>>
>>>>> Thank you to everyone involved!
>>>>>
>>>>> On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote:
>>>>>>
>>>>>> To have this completely working at sprints without having everyone
>>>>>> building their own local images we would need to have the Jenkins server
>>>>>> use docker in some capacity. This would also require an official
>>>>>> django account on Docker hub.
>>>>>>
>>>>>> The pattern I’m using right now is that on every build we pull the
>>>>>> django-ci:latest image (from my personal account). Docker uses this
>>>>>> image as a cache automatically (preventing rebuilds). On any successful
>>>>>> master build we push the new image to docker-hub, so subsequent builds 
>>>>>> can
>>>>>> utilise it.
>>>>>>
>>>>>> Then anyone wanting to speed up their bootstrapping can do docker-compose
>>>>>> pull and automatically have the latest image available for running
>>>>>> right away. We can make this smaller, for sure, but we can also suggest
>>>>>> people download this beforehand (i.e at their hotel).
>>>>>>
>>>>>> I don’t know how feasible this is but it’s also very easy to run a
>>>>>> caching docker mirror (docker run -p 5000:5000 registry). Organizers
>>>>>> could run this at large events and configuring docker to use a local 
>>>>>> mirror
>>>>>> on the network is a one-line change for atendees.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com)
>>>>>> wrote:
>>>>>>
>>>>>> Size of the image could definitely be a concern, especially at
>>>>>> sprints where wifi speeds aren't always optimal. The django-box image is
>>>>>> significantly larger though so it'd still be a net win. There are also
>>>>>> optimisations that can be made to the image for reducing size over time, 
>>>>>> so
>>>>>> I'd fully expect it to come down. I've spent a little bit of time trying 
>>>>>> to
>>>>>> optimise a $work$ python docker file, I'll provide what I've got as an
>>>>>> issue to possibly look at.
>>>>>>
>>>>>> I 

Re: Explore integrating django-docker-box in some way?

[Nick Sarbicki]

Just out of interest, Tom, have you tried using Alpine as the base? Or is
there a reason to avoid it?

I usually find once you introduce all the dependencies for django it
doesn't make a huge difference but it might shave some of the weight off if
we're worried about image size.


- Nick


On Tue, Oct 8, 2019 at 11:52 AM Josh Smeaton  wrote:

> I was going to archive the repo, but it seems I don't have the necessary
> permissions. Carlton, do you?
>
> On Tuesday, 8 October 2019 21:45:22 UTC+11, Adam Johnson wrote:
>>
>> +1 to archiving django-box
>>
>> On Tue, 8 Oct 2019 at 11:01, Tom Forbes  wrote:
>>
>>> Thank you for the kind words Bruno! I'm glad it's helped you, if you
>>> have any suggestions for improvements then please open an issue on the repo
>>> or post a message here, I know it's not perfect. I would have replied
>>> earlier but this message didn't get delivered to me.
>>>
>>> I'm biased, but I'd be +1 on archiving the old django-box. It's served
>>> us well, but unless someone is willing to spend some time updating it then
>>> it's going to confuse new users.
>>>
>>> On Friday, 4 October 2019 12:40:02 UTC+1, Bruno Alla wrote:

 Just a note that as a newish contributor to Django, this
 django-docker-box is fantastic, it makes things much easier to setup.

 Thank you to everyone involved!

 On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote:
>
> To have this completely working at sprints without having everyone
> building their own local images we would need to have the Jenkins server
> use docker in some capacity. This would also require an official
> django account on Docker hub.
>
> The pattern I’m using right now is that on every build we pull the
> django-ci:latest image (from my personal account). Docker uses this
> image as a cache automatically (preventing rebuilds). On any successful
> master build we push the new image to docker-hub, so subsequent builds can
> utilise it.
>
> Then anyone wanting to speed up their bootstrapping can do docker-compose
> pull and automatically have the latest image available for running
> right away. We can make this smaller, for sure, but we can also suggest
> people download this beforehand (i.e at their hotel).
>
> I don’t know how feasible this is but it’s also very easy to run a
> caching docker mirror (docker run -p 5000:5000 registry). Organizers
> could run this at large events and configuring docker to use a local 
> mirror
> on the network is a one-line change for atendees.
>
>
>
>
> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com)
> wrote:
>
> Size of the image could definitely be a concern, especially at sprints
> where wifi speeds aren't always optimal. The django-box image is
> significantly larger though so it'd still be a net win. There are also
> optimisations that can be made to the image for reducing size over time, 
> so
> I'd fully expect it to come down. I've spent a little bit of time trying 
> to
> optimise a $work$ python docker file, I'll provide what I've got as an
> issue to possibly look at.
>
> I see that the ticket has been accepted and I think that's a great
> step forward. I'd also like to hear from the infrastructure team what 
> their
> thoughts on using docker over customised build environments would be.
>
> Florian, Tim, Markus .. any thoughts? (Apologies, I've missed some,
> this list of names is from memory).
>
> On Wednesday, 5 December 2018 10:39:16 UTC+11, Tom Forbes wrote:
>>
>> Thank you for the reply Josh. I didn’t anticipate any suggestions for
>> including this inside core but off the back of your suggestion I’ve made 
>> a
>> ticket here: https://code.djangoproject.com/ticket/30010.
>>
>> I don’t think it should be complex at all to include this inside
>> Django - it’s four or five new files at most. Hopefully this should 
>> improve
>> the experience at sprints, however the current Dockerfile weighs in at
>> 650+mb so the problem may switch from ‘it is hard to set up an 
>> environment’
>> to ‘it is hard to download one’!
>>
>>
>>
>> On 5 November 2018 at 23:02:30, Josh Smeaton (josh.s...@gmail.com)
>> wrote:
>>
>> I'm sorry I haven't had the time to review or contribute yet, but I
>> think it'll be a very useful project - especially for new contributors 
>> that
>> might have a little docker experience. The current vagrant solution is
>> heavy, does not work properly on windows and some linuxes, and isn't that
>> easy to maintain or deploy. I'd be in favour of adding the docker files
>> directly to django/django to minimise setup burden (DJANGO_PATH), and
>> improving the contributing docs to show users how to test using docker.
>>
>> One of the 

Re: Proposal to format Django using black

[Nick Sarbicki]

>
>
> 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 ;)
>
>
Jamie, sure, I wasn't responding directly to you about this, more to the 
general people arguing against blacks style choices. I would happily 
consider alternatives to black - although (without any formal research to 
back this claim) it does feel like black has the most community support.

My point is mostly that if there is a growing community consistency through 
black then I'd be hesitant to choose another tool that goes against this.

 

> > Consistency in the end is the most important thing (even PEP8 agrees 
> > there). 
>
> Not sure where you got that impression: 
> https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds 
> 
>  
>
> Pep8 clearly states consistency is less important then readability (it's 
> the 
> first thing mentioned and mentioned repeatedly that you can use as an 
> argument 
> to break consistency). And this is the primary advantage of black, since 
> readability is hard to quantify (and therefore lint or format) and I think 
> this is where black has succeeded (by breaking consistency where it is 
> needed). 
> I mostly follow the discussion with interest from the sidelines, but just 
> wanted to correct this consistency argument: if you want consistent code, 
> go 
> with autopep8, it'll keep your lines consistent below 79 characters and 
> quite 
> an unreadable mess. 
> -- 
>

Thanks for the correction Melvyn, you're right - aside from readability and 
backwards compatibility consistency is important.

I'd also note the irony of using PEP8 to argue for consistency with a tool 
that is (at least on line length) inconsistent with PEP8. Although I really 
don't want to start a debate on line length.

-- 
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/3041089f-97dd-405e-98ff-e19d53575e1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Nick Sarbicki]

I'm still quite strongly in support of black. I find it's very nice to read
a codebase that has strong consistency (which is historically usually the
work of pedantic but very necessary reviews).

It's even nicer to go between multiple codebases which are all consistent
with each other. PEP8 and linters like flake8 go quite a long way in
achieving this but black goes even further.

There will always be arguments about what standards to use, it's an
unsolvable problem. Some people may think the current Django standards are
perfect, some will prefer blacks defaults, even more will have their own
preferences. I feel that it is arbitrary to make this a major point, it
will never be agreed upon.

Consistency in the end is the most important thing (even PEP8 agrees
there). If we can contribute towards a global consistency in the python
community that would be wonderful. If black is the way the community is
going for this, then that is where my vote is. Even moreso if it lowers the
barrier to entry (I don't think anyone is saying it raises it?).


On Mon, 22 Apr 2019, 07:44 Jamesie Pic,  wrote:

> 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.
>

-- 
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/CAGuvt92iP_Z0niqWw%3D3T0j-BtTL-pyNmrcHPwcE0hHqhQWyMyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Nick Sarbicki]

Just going to say that one of the main frustration points I've had when
making a contribution is having to fix small formatting errors (often minor
things in docstrings which aren't _always_ consistent).

It produces a lot of inertia and can stop PRs from getting merged for
extended periods of time. So from a new contributor angle I think black is
an obvious choice.

>From a maintainers point of view, git blame is very nice to have and this
would add some complexity. But it's easy to see the full version history of
a file and, let's be honest, not enough people use git bisect.


On Sun, 14 Apr 2019, 00:04 Berker Peksağ,  wrote:

> On Sun, Apr 14, 2019 at 1:34 AM Carlton Gibson 
> wrote:
> >
> > We spend a lot of time spotting small formatting errors and then asking
> for those to be fixed and then waiting for an update. This wastes reviewer
> time and slows down the feedback cycle. Many pull requests drag out because
> of it.
>
> But you can now do final edits (cosmetic changes, tweak reST markup
> and documentation) via GitHub UI, right? I always do it to not bother
> contributors with these changes, especially if they are new to the
> project.
>
> --Berker
>
> --
> 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/CAF4280J%2B6J1BJAto1MHd8mo5X%2Bm4AohSqS2HQr3yNXh1WOUcRQ%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/CAGuvt92sVXVAuTzLW7sQkpkJEdNuamfeQwjwcn2dvFokZDZ7CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug in utils.encoding producing invalid JSON for request body

[Nick Sarbicki]

There's been a longer discussion on the ticket about this. The point you
raise I agree with. I also think _encode_data should be left alone.

I still think this should be in framework instead of having to subclass
RequestFactory. Passing in a dict as data should not give invalid JSON.

Instead it would be better to implement an _encode_json. This would be
called if we have the correct content_type within the .post, .patch and
.delete methods. Question for me is how to pass the kwargs in for
json.dumps to allow custom encoders. Or do we not want this (I think we do)?

On Mon, Jan 29, 2018 at 4:50 PM Adam Johnson <m...@adamj.eu> wrote:

> the JSON it produces (it does try)
>>
>
> I wouldn't say it "tries", it just calls str on any object that is passed
> in, which for a simple dict with strings in, looks close to JSON.
> force_bytes definitely shouldn't be trying to JSON-coerce things.
>
> Thus I don't think it's a bug. Bugs are when behaviour doesn't match the
> documentation, and afaict coercing a dict to JSON isn't documented anywhere.
>
> It should be possible to make a subclass of RequestFactory or Client that
> does json.dumps inside _encode_data before calling super(). It's possible
> to swap the self.client on your TestCase subclasses easily by setting
> client_class so you could make it the default in your project.
>
> On 29 January 2018 at 14:14, Nick Sarbicki <nick.a.sarbi...@gmail.com>
> wrote:
>
>> I've just posted a ticket for this here:
>> https://code.djangoproject.com/ticket/29082#ticket
>>
>> The general point is that when I'm using RequestFactory and making a post
>> request with a JSON body, I'd expect to be able to pass in a dict for this
>> - but I can't as the JSON it produces (it does try) is invalid (single
>> instead of double quotes).
>>
>> The fix is three lines in the file but another isinstance call among many.
>>
>> I've been meaning to contribute for a long time and would like this to be
>> my first ticket if I can get confirmation that it _is_ a bug and not
>> intentional.
>>
>> Reproducible example and exact location of offending code are in the
>> ticket.
>>
>> - Nick.
>>
>> --
>> 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/77ab7248-3d6f-4cca-8ddc-27afc49c520c%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/77ab7248-3d6f-4cca-8ddc-27afc49c520c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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/CAMyDDM1biqF10RR9Ybm%3Dbs083PCSQbjwy1LCCM66nOS4B%3DW6rA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1biqF10RR9Ybm%3Dbs083PCSQbjwy1LCCM66nOS4B%3DW6rA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/CAGuvt9216aoAbTSukC0a9VxGitxcx4zhmkqfS%2BFu0oVg%2BYNz4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Bug in utils.encoding producing invalid JSON for request body

[Nick Sarbicki]

I've just posted a ticket for this 
here: https://code.djangoproject.com/ticket/29082#ticket

The general point is that when I'm using RequestFactory and making a post 
request with a JSON body, I'd expect to be able to pass in a dict for this 
- but I can't as the JSON it produces (it does try) is invalid (single 
instead of double quotes).

The fix is three lines in the file but another isinstance call among many.

I've been meaning to contribute for a long time and would like this to be 
my first ticket if I can get confirmation that it _is_ a bug and not 
intentional.

Reproducible example and exact location of offending code are in the ticket.

- Nick.

-- 
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/77ab7248-3d6f-4cca-8ddc-27afc49c520c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Having an --include option for collectsstatic.

[Nick Sarbicki]

I recently found I needed to create a command to include specific files for 
collectstatic and ignore everything else (images and fonts). The opposite 
of the current --ignore functionality.

I've tried to do this with the current --ignore option using glob syntax 
but haven't managed to "ignore all but these file types".

I'm making this functionality now for my project but wondering if it would 
be a welcome addition to django itself?

Looking through the collectstatic code it should be doable by adding 
another if statement at 
https://github.com/django/django/blob/master/django/contrib/staticfiles/utils.py#L26

if include_patterns and not matches_patterns(fn, include_patterns):
continue

And some upstream changes to include "include_patterns" as an option for 
the file finders list methods and the collectstatic command itself.

Setting include_patterns to a default of None should make the addition 
backwards compatible for any third party finders.

Is there any interest in doing this? I accept my current use case is fairly 
niche but it may be useful for others.

Nick.

-- 
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/e0575126-d804-441c-b70a-945d5ffed189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Javascript Templating Package

[Nick Sarbicki]

Hi Daniel,

This is a separate idea. Instead of relying on JSON dumps, we actually
generate an entire JS script via the engine.

The flow is along the lines of:

> Client makes request

> Django receives request and renders an HTML page which it passes to the
client.

> The given HTML page has a script tag which requests a javascript file
from our server.

> Django receives this request and, instead of serving a static javascript
file, renders a javascript file via the templating engine which it then
passes to the client.

This allows us to have more control over the client side scripts based on
what is happening server side.

It's a bit niche - but it cleared up a lot of the legacy JS held in massive
script tags which were overly wasteful and required a lot of tampering
based on server side variables.

On Tue, Oct 11, 2016 at 3:11 PM Daniel Moisset 
wrote:

> Hi Nick, I'm not sure what kind of generation are you suggesting. What
> I've used a couple of times is creating a template tag to convert a
> json-like data structure in the context to a javascript object, so in the
> template I have something like this in a 

Javascript Templating Package

[Nick Sarbicki]

Hi Everyone,

We were tasked at work some time ago with tidying up a legacy Django 
project. Part of the projects JS relied heavily on Django variables and 
settings and we were seeing frequent large variable JSON dumps in the 
templates.

We cleaned this up and ended up designing a small package which allowed us 
to generate Javascript files through the Django templating engine when 
requested by the client.

Since then we've started finding ourselves thinking about using this 
package more and more.

So I was wondering, is this something that the community would be 
interested in? It's not open source yet but we're considering opening up 
the particular package (not least so its more available for us).

If it's not at all of interest, why? Is there a big disadvantage to 
generating Javascript through the templating engine? (assume you, and not 
the client, control the variables going in.

-- 
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/04d4d42d-3bfa-47c6-9ac7-e9d801de9286%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Nick Sarbicki]

>
> Not going to carry this on much more as I doubt I'll be convincing. And
while I, for the most part, agree that group pledges won't change the minds
of those locked to 2.7, I'm hopelessly optimistic about it :-).

And how exactly can that help Django?
>

I think anything which advances and promotes python3 will have direct knock
on effects for Django post 2.0. We all want to see the project thrive, and
if the language it's built on thrives as well that can only be a good thing.


Realistically though, what is stopping us from signing? What negative
>> outcome can it have?
>>
>
> Probably nothing, but Django in the past has never tried to convince
> anyone or force anyone to do something (aside from the decisions we make
> within our framework), and we do not feel the urge to force our view on
> others -- nor sign a pledge for that matter. Our stance on Python 3 is
> clear, we made our point, but we do not need or have to convince anyone
> else.
>

Again I think there's a difference in opinion here. I don't see it as
something we as a project need to convince people of. I see it as a
statement of intent. Django doesn't need to convince anyone, it just needs
to say "this is happening" (and if I had my way in this conversation,
publicly, more than once and in union with other projects...). The
convincing should be left to those using it.

Maybe it would have been better to not have an officially signed list. But
instead just a curated list of projects which have announced that they
won't support 2.7 at some date. Would have been easier and less political.

Nick.

>

-- 
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/CAGuvt920HewnMjjzvn8kYdA8uNL%2BpsgQLxoqy81P9%2B6ro_3O%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Nick Sarbicki]

On my phone so excuse typos.

On Sun, 10 Jul 2016, 13:28 Florian Apolloner, <f.apollo...@gmail.com> wrote:

>
>
> On Saturday, July 9, 2016 at 10:26:25 PM UTC+2, Nick Sarbicki wrote:
>>
>> I don't think this is a question of what it would do for Django. More
>> what Django could do for python.
>
>
> We already announced (way way back), that we are dropping support for
> Python 2 and outlined our plan. That is imo enough, being on a side like
> python3statement.github.io does not add any value to python.
>


The problem with announcing way back is people outside of the sphere
forget. Yes everyone working with Django should know. I know everyone in my
team is very aware of the deadline.

But those outside of Django forget how seriously this is being taken by the
community.

Even then (warning, dumb analogy coming), if I was asked to sign a petition
to my government, I wouldn't refuse just because I'd already written to my
MP about it. Speaking together has more power.

Again, no immediate benefit to Django, but there is one for python.



> The web and scientific communities are essentially the two biggest python
>> communities around. If they both joined together to say "2020 is the
>> deadline for us and everyone else" it could really push a lot of others to
>> see how serious the need to move is now.
>>
>
> Everyone seriously involved in Django (agencies, companies) etc are
> already aware of our plans and are hopefully preparing themselves, if not,
> there is little else we can do which would change their minds…
>

Again, in Django most definitely are. But outside of Django it's less clear.

My last job as an example had a huge pure python programme that is core to
the business. My manager would try to justify upgrading to 3.x but it never
caught on with the seniors. They would look at the stats and see most
people still using 2.7, most libraries still working in 2.7, and see the
current code still running in 2.7. There's never been anything big enough
to convince them.

It didn't run Django so Django announcing wouldn't have any impact. But if
all the major libraries announced then it might have.

Even more to the point (and far worse in my mind) are the teaching websites
like codecademy and learn python the hard way. They all still use python 2!
And to justify it they quote employability and lack of 3.x uptake. Again if
they were to have something bigger put in front of them to show how much of
a dead end 2.7 is, it could push them to change.

If that changes 3.x can get a big push forward. And that in the future can
help Django.

Realistically though, what is stopping us from signing? What negative
outcome can it have?

Nick.

>

-- 
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/CAGuvt90S1oGxePdm14J-xAzT_mPmQE3dk5_F3SZubv_hRssfHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Nick Sarbicki]

Hi Aymeric,

I don't think this is a question of what it would do for Django. More what
Django could do for python.

The web and scientific communities are essentially the two biggest python
communities around. If they both joined together to say "2020 is the
deadline for us and everyone else" it could really push a lot of others to
see how serious the need to move is now.

Python could gain from the greater uptake of 3.x and further downstream
Django will benefit too. I don't find it smug. I think it's a reality check.

Nick.

On Sat, 9 Jul 2016, 07:51 Aymeric Augustin, <
aymeric.augus...@polytechnique.org> wrote:

> Hello Nick,
>
> This website was quickly discussed by a few team members some time ago. It
> wasn’t clear to us what joining this initiative would achieve for Django.
>
> At first sight, it would mostly allow those who run on Python 3 to feel a
> bit more smug and make those who are stuck on Python 2 a bit more
> frustrated.
>
> The web community seems to be ahead of the scientific community for moving
> to Python 3. By now most Django users should be aware that they have to
> figure out a plan to migrate to Python 3 (or JS, or Go, etc.) I don’t think
> the scientific community is there yet.
>
> (To be honest, I discovered recently that some high-profile members of the
> Django community are still advocating to start new projects on Python 2.
> I’m failing to rationalize why they give this advice, certainly because of
> my biais.)
>
> If we consider that we’ve reached a point where we no longer need to focus
> on raising awareness, I’d rather drive the migration to Python 3 with a
> stick than with a carrot. There’s plenty of cool stuff to advertise :-)
>
> --
> Aymeric.
>
> On 09 Jul 2016, at 04:03, Nick Timkovich  wrote:
>
> With the release of IPython 5.0 LTS, it was mentioned as also being the
> final Py2-compat release in the series with a reference to the "Python 3
> Statement" https://python3statement.github.io/ Some of the prose in it
> refers to just the Scientific Stack (Numpy, Scipy, MPL, et al.), but an
> issue popped up saying that it could be generalized if other projects were
> to join/"sign", e.g. Django.
> https://github.com/python3statement/python3statement.github.io/issues/21
>
> I'm not strongly advocating one way or the other, just thought I'd bring
> it up.
>
> Nick
>
> --
> 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/0460ab73-1059-49e9-be63-2716378fddca%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/7E8B9E8B-D60E-48E4-BDB5-969BC4479EDF%40polytechnique.org
> 
> .
> 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/CAGuvt91Fw%2Bayc02jyW_-8hxj1_sekJvfkuUQsi0Ft566gyZ92w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Nick Sarbicki]

Same boat for me.

I constantly need the JSON field but can't always rely on postgres.

-- 
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/CAGuvt930QvCKazawJbH_OpHwqSpSw74TtgEKR1Tpp2Yh23WLuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Nick Sarbicki]

>
> FWIW Jira seems to be an exception among bug trackers: some people really
> love it, others really hate it. It depends on who set it up and maintained
> it in the company where they used it.
>
> Since we don’t have a resident Jira expert, we run the risk that most of
> the Django community will fall into the “hate it” bucket. To me this is one
> of the riskier choices we could make.
>
> Anyway it’s unclear to me that the potential benefits of switching to any
> bug tracker could offset the transition costs, as long as Trac is
> serviceable.
>
> We’ll see what happens in 2020 if it doesn’t support Python 3 by then (
> http://trac.edgewall.org/ticket/10083,
> http://trac.edgewall.org/ticket/12130).
>

Could always look at Bloodhound (http://bloodhound.apache.org/) if after
something similar. Not that it supports Py3 yet.

But I'm with everyone else. It's not worth it.

-- 
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/CAGuvt93%2BabKpnA%2BFC2Ny5HYn3p_8mdS_%2BrPV3jg3NFoV%3DgHvyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

To make myself clear. I don't think we need to document this as it is not a 
django error. 

It is a Python error because the module was not installed correctly.

Maybe there should be a mention of the difference for installation on 
Ubuntu (and other linux distros?). But this would be unusual for anyone 
using Windows or Mac as they won't have a default Python install and will 
often only have 1 version, so 1 pip.

- Nick.

On Wednesday, September 9, 2015 at 3:05:15 PM UTC+1, Nick Sarbicki wrote:
>
> In which case you need to install it again with *pip3*.
>
> All the defaults in Ubuntu (Python, pip etc.) are focused on 2.7, you 
> always need to append 3 if you want it to be *python3 *specific.
>
> For earlier versions of ubuntu this was because some core processes 
> required python2.7 and would call it through *python*. I think they are 
> past that with the latest release, but from memory there is a *pep* somewhere 
> which states that this should remain the standard for now.
>
> - Nick.
>
> On Wednesday, September 9, 2015 at 2:58:36 PM UTC+1, Anjul Tyagi(geety) 
> wrote:
>>
>> yes, I installed django using *pip *and not* pip3.*
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/507c7031-f5e6-46ca-b6e1-1811cc600e8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

In which case you need to install it again with *pip3*.

All the defaults in Ubuntu (Python, pip etc.) are focused on 2.7, you 
always need to append 3 if you want it to be *python3 *specific.

For earlier versions of ubuntu this was because some core processes 
required python2.7 and would call it through *python*. I think they are 
past that with the latest release, but from memory there is a *pep* somewhere 
which states that this should remain the standard for now.

- Nick.

On Wednesday, September 9, 2015 at 2:58:36 PM UTC+1, Anjul Tyagi(geety) 
wrote:
>
> yes, I installed django using *pip *and not* pip3.*
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8e361d61-ee46-4b00-8536-a1ebc0a1ac65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to document the error on trying to import django in python 3.4.

[Nick Sarbicki]

Can you show us how you installed django?

More specifically, did you do 

*pip install django*

and

*pip3 install django*

As it looks like you only install django for 2.7, and not for 3.4.

- Nick.

On Wednesday, September 9, 2015 at 2:51:07 PM UTC+1, Anjul Tyagi(geety) 
wrote:
>
> Hi everyone,
>
> I am new to django and wish to address the problem which I faced during 
> the installation of django on Ubuntu 14.04.
> I had two versions of python installed before I installed django: python 
> 2.7.6 and python 3.4. I installed django as per the steps given in the 
> documentation.
> Now, 
> If I type the following on the terminal:
>
>
> *python>>>import django*
>
> It works correctly, but
>
>
> *python3>>>import django*
>
> shows the module not found error 
> .
>  
> I think we can document this inside the "verifying" section of the "Quick 
> Installation guide" part of documentation just to make sure that new users 
> don't panic seeing this error.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1eedff19-6212-4b49-8521-7889ce30dfec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django with Pycharm

[Nick Sarbicki]

Hi Prabhu,

Are you using the community or professional version?

The community version doesn't support specific Django projects (although it
is still good to use).

https://www.jetbrains.com/pycharm/features/editions_comparison_matrix.html

Nick.

On Fri, Sep 4, 2015 at 3:47 PM Prabhu  wrote:

> Hi Team,
>
> I'm Prabhu new to django, i'm trying configure to debug django appication
> using pycharm.
>
> I could not locate/select project type as "Django"
>
> Please hep me out to resolve this issue to move forward to debug my
> project.
>
> Using Ubuntu 15.04, Django,Pycharm & Python installed
>
> Thanks and Regards,
>
> Prabhu
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/62d50e77-ba53-4da5-bf07-326ee89fd75e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
 - Nick

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGuvt90rePWrS9uRe1XSEg1nH0G9VXoM81S4naDEJox%2B%3DZfv8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Nick Sarbicki]

This takes the conversation back a ways...

But I like the idea of being able to customise the admin scheme. Enforce a 
default of course, but maybe have some options (in admin.py? or as a 
separate script?) which can change the core colors of the scheme, either a 
set of predefined colours, or something completely customisable by the 
user. 

I don't think it's a huge amount of work (it's finding and replacing hex 
values in the css files). But I reckon it could add a lot of value for 
people who want the admin page to match the scheme of their website.

Obviously not a good idea to shove it in before the 1.9 release, but if the 
idea is liked I might (or any one else who is interested) be able to look 
into it.

/Nick.

On Monday, March 16, 2015 at 1:44:23 PM UTC, Tim Graham wrote:
>
> In some previous discussion, it was suggested to have a toggle between the 
> new and old designs to ease the transition. I guess this could be something 
> like a "theme" attribute on AdminSite. Do you think this is required? It 
> seems this could be a non-trivial maintenance burden if we have to test and 
> maintain two designs for some time.
>
> On Friday, March 13, 2015 at 7:42:35 AM UTC-4, elky wrote:
>>
>> Did you test RTL?
>>>
>>> I did. I tested Arabic and Hebrew - no issues detected for me. BUT. As 
>>> far as I understand Django admin has poor RTL support by itself.
>>>
>>
>> Sorry guys, I was wrong about it. Django has very good RTL support! Just 
>> didn't notice right setting to test it. But anyway I did few tweaks in my 
>> theme. 
>>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8499ebc7-c562-4e86-bb89-46a15ac7c906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.