Re: Redis cache support in core

[Josh Smeaton]

Markus, I'd prefer that approach over vendoring a more incomplete solution. 
Bonus points if we can add packages to extra_requires, so that `pip install 
Django[redis]` would work nicely.

On Friday, 21 June 2019 23:17:25 UTC+10, Markus Holtermann wrote:
>
> Hi all, 
>
> may I suggest that django-redis may be "promoted" to an official Django 
> package under the Django GitHub organization? This would follow 
> https://github.com/django/deps/blob/master/final/0007-official-projects.rst 
> . The package would be pointed out explicitly in the Django docs but would 
> be shipped outside of Django. 
>
> The benefit with 3rd party packets is their shorter release cycle. Which, 
> in the context of django-redis could be beneficial . 
>
> /Markus 
>
> On Fri, Jun 21, 2019, at 2:43 PM, 'Ivan Anishchuk' via Django developers 
>  (Contributions to Django itself) wrote: 
> > I wouldn't say it's that complicated a setup. It would require a single 
> > settings snippet -- just like the ones for other backends -- and, I 
> > guess, a link to django-redis docs for more details (if django-redis is 
> > what we recommend), maybe a quick explanation of what is CLIENT_CLASS 
> > and other options. While it would add some maintenance burden 
> > (occasionally checking whether any breaking changes were introduced in 
> > the 3rd party package that require updating settings) it's still way 
> > easier than adding a backend to django core. 
> > 
> > While I agree with others about redis being popular and adding such a 
> > backend in django being a good idea (I would love if that happened) I 
> > understand the reasons for not doing it. A recommendation of a 3rd 
> > party package + setup documentation, on the other hand, is pretty 
> > simple thing to do. 
> > 
> > If we want, it's also not very hard to provide 
> > `django.core.cache.backend.redis.Redis Cache` that depends on 
> > django-redis and is an alias for `django_redis.cache.RedisCache` -- 
> > it's basically the way it works with DB backends, I don't see why it 
> > wouldn't be a good idea for cache as well. 
> > 
> > Ivan. 
> > 
> > On Thu, Jun 20, 2019, 04:02 Josh Smeaton  > wrote: 
> > > Celery explicitly document their integration with Redis though. I 
> don't think we want to take over documenting the setup of a 3rd party 
> package in Django. 
> > > 
> > > On Thursday, 20 June 2019 11:00:27 UTC+10, Ivan Anishchuk wrote: 
> > >> How about making one of the third-party packages an optional 
> dependency? Celery, for example, does that: you can just install 
> celery[redis] without having to figure out what other packages you need to 
> enable redis support. 
> > >> 
> > >> Ivan. 
> > >> 
> > >> On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton  
> wrote: 
> > >>> There are already several 3rd party packages that implement redis as 
> a django cache backend, for example https://github.com/niwinz/django-redis 
> > >>> 
> > >>> We already have a base class for cache backends - and several 
> implementing it (such as memcache). I don't think there's much benefit 
> taking on another backend when it's already got very good support as an 
> external package. 
> > >>> 
> > >>> 
> > >>> On Tuesday, 18 June 2019 01:14:25 UTC+10, Dulmandakh Sukhbaatar 
> wrote: 
> >  Hello, 
> >  
> >  I would like to work on Redis support in core, and I would like to 
> discuss proper solution for that. 
> >  
> >  Redis is getting so popular and almost every modern backend stack 
> uses it someway, therefore I think that supporting it as a cache backend in 
> core would make Django more appealing. A solution I'm proposing is to 
> extract base KV backend from current Memcached and extend it for both 
> Memcached and Redis, and this won't add many new code to the core. Also 
> we'll have base class for KV storage backends. 
> >  
> >  Thanks. 
> > 
> > >>>  -- 
> > >>>  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 post to this group, send email to django-d...@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/bdb84d20-0489-4ecd-b198-fa5878f5c617%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/bdb84d20-0489-4ecd-b198-fa5878f5c617%40googlegroups.com?utm_medium=email&utm_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-d...@googlegroups.com . 
> > >  To post t

Discussing improvements of django.setup()

[Pkl]

Hello everyone,

I'm bringing here, for broader review and discussion, the subject of making 
django setup more "tweakable":
https://code.djangoproject.com/ticket/30536
https://github.com/django/django/pull/11435

There is indeed a need for doing pre/post operations at that crucial moment 
of the framework lifetime, especially to apply compatibility shims 
(greening-related, API stability-related...) and setup test scaffolding, 
stubs etc.

A separate PR has been created to handle threadsafety/idempotence 
(https://github.com/django/django/pull/11440) when multiple actors try to 
setup django concurrently, but a discussion remains on how to potentially 
allow users to specify an alternative setup 

I originally did a POC with a new django setting, but if we want to have 
full control, even settings might not be normally loaded at that stage. So 
maybe, as apollo13 suggested, an environment variable, like 
DJANGO_SETUP_CALLABLE, complementing the DJANGO_SETTINGS_MODULE one?
What are your thoughts about this ?

thanks,
regards,
Pakal

-- 
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/0206c98c-199f-49f9-9ff7-cba736e71224%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resource loading (Django without a filesystem)

[Peter Baumgartner]

Unfortunately you can't load resources from implicit namespace
packages. It raises `FileNotFoundError: Package has no location
`
The __init__.py appears to be required.

On Thu, Jun 27, 2019 at 3:05 PM Andrew Godwin  wrote:
>
> Well, remember that in Python 3 you don't need an __init__.py file to have 
> something be a module (because of  
> https://www.python.org/dev/peps/pep-0420/), but I wonder if there still needs 
> to be a proper discovery mechanism that flags that they should be considered 
> as implicit packages/modules.
>
> Andrew
>
> On Thu, Jun 27, 2019 at 2:01 PM Peter Baumgartner  
> wrote:
>>
>> The big issue I see is that a resource must reside directly in a
>> Python module. You can not load a resource from a child directory,
>> e.g. I can load "index.html" from the Python module
>> "myproject.templates", but I can't load "app1/index.html" from the
>> same module.
>>
>> This would require developers to scatter __init__.py files in every
>> template directory. I think migrations would be easy (you can list
>> Python files in a module without the filesystem). I need to look at
>> how staticfiles works a little closer. I think we could still use
>> __file__ for collectstatic (you would run that before converting your
>> project), but I'm not sure what Django needs access to at runtime
>> there.
>>
>> Pytz is also an issue. It looks like an easier fix there because the
>> project controls the "resource" directories and could sprinkle in the
>> necessary __init__.py files. I filed an issue to start the discussion
>> there as well, https://bugs.launchpad.net/pytz/+bug/1834363
>>
>> On Thu, Jun 27, 2019 at 2:40 PM Andrew Godwin  wrote:
>> >
>> > My impression reading over the problem a little yesterday was that we 
>> > could work to provide a common "get me a resource" abstraction in Django 
>> > that papers over the couple of different ways it has to work, though I 
>> > haven't looked super far into things that require directory listing (e.g. 
>> > migrations) rather than direct file access (like templates).
>> >
>> > It would be nice to investigate this a bit more, though. If we can get 
>> > Django compatible, or work with PyOxidiser if we find a reasonable 
>> > workaround they could implement, it would be great.
>> >
>> > Andrew
>> >
>> > On Thu, Jun 27, 2019 at 12:39 PM Markus Holtermann 
>> >  wrote:
>> >>
>> >> Hi Peter,
>> >>
>> >> PyOxidizer looks indeed super interesting. Talking about templates and 
>> >> specifically Jinja2 templates, they are internally converted to the 
>> >> Python AST if I'm not mistaking. Turning them into Python modules that a 
>> >> new Jinja2ModuleTemplateLoader could load doesn't seem like that far 
>> >> fetched.
>> >>
>> >> Similarly for Django's migration files. Swapping out the MigrationLoader 
>> >> would already be sufficient.
>> >>
>> >> I'd definitely be interested to see what's needed to change in core to 
>> >> have a 3rd party package provide the necessary support.
>> >>
>> >> Cheers,
>> >>
>> >> Markus
>> >>
>> >> On Thu, Jun 27, 2019, at 9:09 PM, Peter Baumgartner wrote:
>> >> > I'm interested in using PyOxidizer [1] to create single-file executable
>> >> > Django projects. This currently isn't possible because of all the
>> >> > places Django assumes it is operating on a proper filesystem. I haven't
>> >> > done a full audit, but templates, migrations, and static files come to
>> >> > mind. Python has full support this scenario (aka resource loading), but
>> >> > it would require some changes to Django internals to use it. One of the
>> >> > biggest hurdles I see on the surface is that you can only load a
>> >> > resource from a Python module (not from a sub-directory). That being
>> >> > said, I have a feeling resource loading could be added such that users
>> >> > could opt-in or backwards compatibility is maintained with the current
>> >> > implementation.
>> >> >
>> >> > Some additional reading/watching on the subject:
>> >> >
>> >> > * Topic overview:
>> >> > https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
>> >> > * Barry Warsaw talk on resource loading:
>> >> > https://www.youtube.com/watch?v=ZsGFU2qh73E
>> >> >
>> >> > I'm posting here to see if there is general support for this and to
>> >> > discuss what sort of changes would be required. Thanks!
>> >> >
>> >> > [1] https://pyoxidizer.readthedocs.io/
>> >> >
>> >> >  --
>> >> >  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/b6229b20-0

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

[Pkl]

Just for reference, here is a package I crossed recently and which has an 
approach for that : https://github.com/3YOURMIND/django-deprecate-fields

On Monday, June 24, 2019 at 3:15:04 PM UTC+2, Matthieu Rudelle wrote:
>
> Hi there, 
>
> I can't find any previous ticket proposing a solution to this problem so 
> here are my findings: 
>
> **Use case**:
> When using continuous delivery several versions of the code can be running 
> in parallel on se same DB. Say for instance that release 2.42 is in 
> production, 2.43 is about to be rolled out and in this release one field 
> (say ''MyModel.my_unused_field'') is not used anymore and was removed. 
> Before rolling out 2.43 the DB is migrated and column ''my_unused_field'' 
> of ''MyModel'' is removed. This makes 2.42 crash saying that one column is 
> not found even though 2.42 does not use the field anywhere in the code.
>
> **Temporary solution**:
> Do not makemigrations until de 2.44 release, but it does not scale well 
> with many contributors and CI tools (doing their awesome job of making sure 
> migrations and models are in sync) will complain.
>
> **Proposed solution**:
> Have a ''disabled'' param on Field. When activated this field is not 
> fetched from the DB but replaced by a hardcoded value. 
> In our use case, ''disabled'' is added at the 2.42 release, then when 2.43 
> rolls out and migrates the DB no error is thrown.
>
> **Refs**:
> - django-users discussion: 
> https://groups.google.com/forum/#!topic/django-users/HY_6rZZ0Kk8
> - the same problem discussed in this article, but with a slightly 
> different solution: 
> https://pankrat.github.io/2015/django-migrations-without-downtimes/#django-wishlist
>  
> (third item in the wishlist)
> - Previous django-developpers discussion: 
> https://groups.google.com/d/msg/django-developers/5ofrxeLT95E/XhppgA_KAQAJ
>
> What do you guys think?
>

-- 
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/d05e7d82-b7cd-4ced-a23c-d3c9dfa3b826%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resource loading (Django without a filesystem)

[Andrew Godwin]

Well, remember that in Python 3 you don't need an __init__.py file to have
something be a module (because of  https://www.python.org/dev/peps/pep-0420/),
but I wonder if there still needs to be a proper discovery mechanism that
flags that they should be considered as implicit packages/modules.

Andrew

On Thu, Jun 27, 2019 at 2:01 PM Peter Baumgartner 
wrote:

> The big issue I see is that a resource must reside directly in a
> Python module. You can not load a resource from a child directory,
> e.g. I can load "index.html" from the Python module
> "myproject.templates", but I can't load "app1/index.html" from the
> same module.
>
> This would require developers to scatter __init__.py files in every
> template directory. I think migrations would be easy (you can list
> Python files in a module without the filesystem). I need to look at
> how staticfiles works a little closer. I think we could still use
> __file__ for collectstatic (you would run that before converting your
> project), but I'm not sure what Django needs access to at runtime
> there.
>
> Pytz is also an issue. It looks like an easier fix there because the
> project controls the "resource" directories and could sprinkle in the
> necessary __init__.py files. I filed an issue to start the discussion
> there as well, https://bugs.launchpad.net/pytz/+bug/1834363
>
> On Thu, Jun 27, 2019 at 2:40 PM Andrew Godwin  wrote:
> >
> > My impression reading over the problem a little yesterday was that we
> could work to provide a common "get me a resource" abstraction in Django
> that papers over the couple of different ways it has to work, though I
> haven't looked super far into things that require directory listing (e.g.
> migrations) rather than direct file access (like templates).
> >
> > It would be nice to investigate this a bit more, though. If we can get
> Django compatible, or work with PyOxidiser if we find a reasonable
> workaround they could implement, it would be great.
> >
> > Andrew
> >
> > On Thu, Jun 27, 2019 at 12:39 PM Markus Holtermann <
> i...@markusholtermann.eu> wrote:
> >>
> >> Hi Peter,
> >>
> >> PyOxidizer looks indeed super interesting. Talking about templates and
> specifically Jinja2 templates, they are internally converted to the Python
> AST if I'm not mistaking. Turning them into Python modules that a new
> Jinja2ModuleTemplateLoader could load doesn't seem like that far fetched.
> >>
> >> Similarly for Django's migration files. Swapping out the
> MigrationLoader would already be sufficient.
> >>
> >> I'd definitely be interested to see what's needed to change in core to
> have a 3rd party package provide the necessary support.
> >>
> >> Cheers,
> >>
> >> Markus
> >>
> >> On Thu, Jun 27, 2019, at 9:09 PM, Peter Baumgartner wrote:
> >> > I'm interested in using PyOxidizer [1] to create single-file
> executable
> >> > Django projects. This currently isn't possible because of all the
> >> > places Django assumes it is operating on a proper filesystem. I
> haven't
> >> > done a full audit, but templates, migrations, and static files come to
> >> > mind. Python has full support this scenario (aka resource loading),
> but
> >> > it would require some changes to Django internals to use it. One of
> the
> >> > biggest hurdles I see on the surface is that you can only load a
> >> > resource from a Python module (not from a sub-directory). That being
> >> > said, I have a feeling resource loading could be added such that users
> >> > could opt-in or backwards compatibility is maintained with the current
> >> > implementation.
> >> >
> >> > Some additional reading/watching on the subject:
> >> >
> >> > * Topic overview:
> >> >
> https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
> >> > * Barry Warsaw talk on resource loading:
> >> > https://www.youtube.com/watch?v=ZsGFU2qh73E
> >> >
> >> > I'm posting here to see if there is general support for this and to
> >> > discuss what sort of changes would be required. Thanks!
> >> >
> >> > [1] https://pyoxidizer.readthedocs.io/
> >> >
> >> >  --
> >> >  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/b6229b20-0647-4e0a-b9e6-31136a774e13%40googlegroups.com
> <
> https://groups.google.com/d/msgid/django-developers/b6229b20-0647-4e0a-b9e6-31136a774e13%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >> >  For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >> You received this message because you are subscribed to th

Re: Resource loading (Django without a filesystem)

[Peter Baumgartner]

The big issue I see is that a resource must reside directly in a
Python module. You can not load a resource from a child directory,
e.g. I can load "index.html" from the Python module
"myproject.templates", but I can't load "app1/index.html" from the
same module.

This would require developers to scatter __init__.py files in every
template directory. I think migrations would be easy (you can list
Python files in a module without the filesystem). I need to look at
how staticfiles works a little closer. I think we could still use
__file__ for collectstatic (you would run that before converting your
project), but I'm not sure what Django needs access to at runtime
there.

Pytz is also an issue. It looks like an easier fix there because the
project controls the "resource" directories and could sprinkle in the
necessary __init__.py files. I filed an issue to start the discussion
there as well, https://bugs.launchpad.net/pytz/+bug/1834363

On Thu, Jun 27, 2019 at 2:40 PM Andrew Godwin  wrote:
>
> My impression reading over the problem a little yesterday was that we could 
> work to provide a common "get me a resource" abstraction in Django that 
> papers over the couple of different ways it has to work, though I haven't 
> looked super far into things that require directory listing (e.g. migrations) 
> rather than direct file access (like templates).
>
> It would be nice to investigate this a bit more, though. If we can get Django 
> compatible, or work with PyOxidiser if we find a reasonable workaround they 
> could implement, it would be great.
>
> Andrew
>
> On Thu, Jun 27, 2019 at 12:39 PM Markus Holtermann  
> wrote:
>>
>> Hi Peter,
>>
>> PyOxidizer looks indeed super interesting. Talking about templates and 
>> specifically Jinja2 templates, they are internally converted to the Python 
>> AST if I'm not mistaking. Turning them into Python modules that a new 
>> Jinja2ModuleTemplateLoader could load doesn't seem like that far fetched.
>>
>> Similarly for Django's migration files. Swapping out the MigrationLoader 
>> would already be sufficient.
>>
>> I'd definitely be interested to see what's needed to change in core to have 
>> a 3rd party package provide the necessary support.
>>
>> Cheers,
>>
>> Markus
>>
>> On Thu, Jun 27, 2019, at 9:09 PM, Peter Baumgartner wrote:
>> > I'm interested in using PyOxidizer [1] to create single-file executable
>> > Django projects. This currently isn't possible because of all the
>> > places Django assumes it is operating on a proper filesystem. I haven't
>> > done a full audit, but templates, migrations, and static files come to
>> > mind. Python has full support this scenario (aka resource loading), but
>> > it would require some changes to Django internals to use it. One of the
>> > biggest hurdles I see on the surface is that you can only load a
>> > resource from a Python module (not from a sub-directory). That being
>> > said, I have a feeling resource loading could be added such that users
>> > could opt-in or backwards compatibility is maintained with the current
>> > implementation.
>> >
>> > Some additional reading/watching on the subject:
>> >
>> > * Topic overview:
>> > https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
>> > * Barry Warsaw talk on resource loading:
>> > https://www.youtube.com/watch?v=ZsGFU2qh73E
>> >
>> > I'm posting here to see if there is general support for this and to
>> > discuss what sort of changes would be required. Thanks!
>> >
>> > [1] https://pyoxidizer.readthedocs.io/
>> >
>> >  --
>> >  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/b6229b20-0647-4e0a-b9e6-31136a774e13%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/2faec64a-da9f-4d55-9378-a3cb6a308d53%40www.fastmail.com.
>> For more opti

Re: Resource loading (Django without a filesystem)

[Andrew Godwin]

My impression reading over the problem a little yesterday was that we could
work to provide a common "get me a resource" abstraction in Django that
papers over the couple of different ways it has to work, though I haven't
looked super far into things that require directory listing (e.g.
migrations) rather than direct file access (like templates).

It would be nice to investigate this a bit more, though. If we can get
Django compatible, or work with PyOxidiser if we find a reasonable
workaround they could implement, it would be great.

Andrew

On Thu, Jun 27, 2019 at 12:39 PM Markus Holtermann 
wrote:

> Hi Peter,
>
> PyOxidizer looks indeed super interesting. Talking about templates and
> specifically Jinja2 templates, they are internally converted to the Python
> AST if I'm not mistaking. Turning them into Python modules that a new
> Jinja2ModuleTemplateLoader could load doesn't seem like that far fetched.
>
> Similarly for Django's migration files. Swapping out the MigrationLoader
> would already be sufficient.
>
> I'd definitely be interested to see what's needed to change in core to
> have a 3rd party package provide the necessary support.
>
> Cheers,
>
> Markus
>
> On Thu, Jun 27, 2019, at 9:09 PM, Peter Baumgartner wrote:
> > I'm interested in using PyOxidizer [1] to create single-file executable
> > Django projects. This currently isn't possible because of all the
> > places Django assumes it is operating on a proper filesystem. I haven't
> > done a full audit, but templates, migrations, and static files come to
> > mind. Python has full support this scenario (aka resource loading), but
> > it would require some changes to Django internals to use it. One of the
> > biggest hurdles I see on the surface is that you can only load a
> > resource from a Python module (not from a sub-directory). That being
> > said, I have a feeling resource loading could be added such that users
> > could opt-in or backwards compatibility is maintained with the current
> > implementation.
> >
> > Some additional reading/watching on the subject:
> >
> > * Topic overview:
> >
> https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
> > * Barry Warsaw talk on resource loading:
> > https://www.youtube.com/watch?v=ZsGFU2qh73E
> >
> > I'm posting here to see if there is general support for this and to
> > discuss what sort of changes would be required. Thanks!
> >
> > [1] https://pyoxidizer.readthedocs.io/
> >
> >  --
> >  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/b6229b20-0647-4e0a-b9e6-31136a774e13%40googlegroups.com
> <
> https://groups.google.com/d/msgid/django-developers/b6229b20-0647-4e0a-b9e6-31136a774e13%40googlegroups.com?utm_medium=email&utm_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/2faec64a-da9f-4d55-9378-a3cb6a308d53%40www.fastmail.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/CAFwN1ur36dYm7xohN0PQRkY3Y8H5m8-Ws307Wo-u%2B3xMtjLBKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resource loading (Django without a filesystem)

[Markus Holtermann]

Hi Peter,

PyOxidizer looks indeed super interesting. Talking about templates and 
specifically Jinja2 templates, they are internally converted to the Python AST 
if I'm not mistaking. Turning them into Python modules that a new 
Jinja2ModuleTemplateLoader could load doesn't seem like that far fetched.

Similarly for Django's migration files. Swapping out the MigrationLoader would 
already be sufficient.

I'd definitely be interested to see what's needed to change in core to have a 
3rd party package provide the necessary support.

Cheers,

Markus

On Thu, Jun 27, 2019, at 9:09 PM, Peter Baumgartner wrote:
> I'm interested in using PyOxidizer [1] to create single-file executable 
> Django projects. This currently isn't possible because of all the 
> places Django assumes it is operating on a proper filesystem. I haven't 
> done a full audit, but templates, migrations, and static files come to 
> mind. Python has full support this scenario (aka resource loading), but 
> it would require some changes to Django internals to use it. One of the 
> biggest hurdles I see on the surface is that you can only load a 
> resource from a Python module (not from a sub-directory). That being 
> said, I have a feeling resource loading could be added such that users 
> could opt-in or backwards compatibility is maintained with the current 
> implementation.
> 
> Some additional reading/watching on the subject:
> 
> * Topic overview: 
> https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
> * Barry Warsaw talk on resource loading: 
> https://www.youtube.com/watch?v=ZsGFU2qh73E
> 
> I'm posting here to see if there is general support for this and to 
> discuss what sort of changes would be required. Thanks!
> 
> [1] https://pyoxidizer.readthedocs.io/
> 
>  -- 
>  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/b6229b20-0647-4e0a-b9e6-31136a774e13%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/2faec64a-da9f-4d55-9378-a3cb6a308d53%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Resource loading (Django without a filesystem)

[Peter Baumgartner]

I'm interested in using PyOxidizer [1] to create single-file executable 
Django projects. This currently isn't possible because of all the places 
Django assumes it is operating on a proper filesystem. I haven't done a 
full audit, but templates, migrations, and static files come to mind. 
Python has full support this scenario (aka resource loading), but it would 
require some changes to Django internals to use it. One of the biggest 
hurdles I see on the surface is that you can only load a resource from a 
Python module (not from a sub-directory). That being said, I have a feeling 
resource loading could be added such that users could opt-in or backwards 
compatibility is maintained with the current implementation.

Some additional reading/watching on the subject:

* Topic overview: 
https://pyoxidizer.readthedocs.io/en/latest/packaging_pitfalls.html#reliance-on-file
* Barry Warsaw talk on resource loading: 
https://www.youtube.com/watch?v=ZsGFU2qh73E

I'm posting here to see if there is general support for this and to discuss 
what sort of changes would be required. Thanks!

[1] https://pyoxidizer.readthedocs.io/

-- 
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/b6229b20-0647-4e0a-b9e6-31136a774e13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Difficulty setting dynamic 'db_table' in Meta

[Adam Johnson]

So it looks to me like migrations feeds off of models.original_attrs:
https://github.com/django/django/blob/master/django/db/models/options.py#L160
 /
https://github.com/django/django/blob/master/django/db/migrations/state.py#L453

This is set at contribute_to_class time in the Meta. The __new__ method in
the SO post mutates _meta but not its original_attrs. I think if it was
changed to mutate original_attrs as well, it would work.


On Wed, 26 Jun 2019 at 17:41, Brock Hallenbeck 
wrote:

> Sorry for the confusion. That post is not actually me, just an identical
> situation. I am in fact on 2.2. It's just frustrating because I can raise
> an arbitrary exception in my metaclass and makemigrations will fail because
> of it, so I know the code is being run. It just seems to be inexplicably
> ignored.
>
> I will look into the decorator, although I am sad i'll be losing
> inheritance.
>
> On Wednesday, June 26, 2019 at 12:01:31 PM UTC-4, Adam Johnson wrote:
>>
>> Hi,
>>
>> The SO post shows you (?) testing on Django 1.10, have you tried with the
>> latest 2.2?
>>
>> You could also try implementing this with just a class decorator which is
>> much more likely to work, although it’s not inheritable.
>>
>> You could also enforce with a a custom system check for manual
>> declaration of db_table. It could iterate over the models in your project’s
>> apps and return one check Error for each model with a db_table that doesn’t
>> match the desired naming scheme.
>>
>> Thanks,
>>
>> Adam
>>
>> On Wed, 26 Jun 2019 at 15:50, Brock Hallenbeck 
>> wrote:
>>
>>> I am trying to modify django's default table naming scheme to better
>>> suit my needs and am having some difficulty.
>>>
>>> In order to accomplish this I need access to the 'app_label' and
>>> 'model_name' attributes. However due to python's scoping, I am unable to do
>>> so in your standard Meta subclass.
>>>
>>> I have successfully implemented a custom metaclass, that overrides
>>> __new__ in order to set the 'db_table' attribtue to what I want, however
>>> upon running makemigrations, this custom behavior is seemingly ignored.
>>>
>>> This stack overflow question illustrates the problem.
>>> 
>>>
>>> Is there some magic that I am not aware of going on inside
>>> makemigrations?
>>>
>>> --
>>> 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 post to this group, send email to django-d...@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/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.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/e0061fa8-8f09-4ba2-ba67-34b55b0e7d74%40googlegroups.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/CAMyDDM0tTOtAVBkzK25hZ5WCm4T9EFXvxQ6z6jR%3D%3DdyM-ZA%2BRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.