Re: #21978 include production-ready web server

[Peter Baumgartner]

On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner 
wrote:

> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> In my ideal scenario, the default is a hard-coded settings file for the
>> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
>> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
>> Perhaps things like django.setup,
>>
> django.core.wsgi.get_wsgi_application, and
>> django.core.management.execute_from_command_line could accept the settings
>> module as an argument? django-admin could accept a --settings flag?
>>
>
> I doubt that will ever fly. There is no project so to say in Django.
> Currently literally everything depends on knowing a
> `DJANGO_SETTINGS_MODULE` from which everything else can follow (even the
> wsgi app…). So without a settings file how would you know that hard-coded
> path for it? Django has no concept of a project that you could import. You
> also cannot easily put `CONFIG_LOADERS` in a settings file like we
> currently have because then how are you going to evaluate that while also
> executing all the other module level stuff. And django-admin command all
> already support a `--settings` flag (as alternative to
> DJANGO_SETTINGS_MODULE ;))
>
> Either way I doubt we will deprecating DJANGO_SETTINGS_MODULE any time
> soon. And I don't see it such of a problem with being there. Projects can
> set it (and startproject already does this) to a fixed value in manage.py &
> wsgi.py. For a project that installs a custom entrypoint script, you can
> also preset it to whatever you like.
>
> Please note that we are trying to load stuff from files & env vars in the
> first step, not throw out settings.py at the same time…
>

I figured it wouldn't fly :)

I misunderstood your chicken-egg question above. What I've been doing is
defining a "Config" class and instantiating it in the settings file.
Instantiation of the class (or calling an explicit method on it) would do
the env/file loading and the instance becomes your `env` object. Rather
than having a CONFIG_LOADERS setting, you could define them on the Config
class or when you instantiate it. This is pretty similar to how goodconf
works today. https://github.com/lincolnloop/goodconf#quick-start


>
> Cheers,
> Florian
>
> --
> 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/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%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/CAC6K9znR0RwrW%2B9SVMOy56mg%3DOuAYafBExGJf8n-TFdefhhKeA%40mail.gmail.com.

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Sun, Oct 30, 2022 at 7:57 AM Florian Apolloner 
wrote:

> Hi Peter,
>
> On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
> wrote:
>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary widely).
>>>
>>
>> Production environments do vary widely, but I don't think that should
>> stop us from providing defaults that are one-size-fits-most. startproject
>> already does this and users are welcome to adjust it how they see fit.
>>
>
> Agreed, I should have written this better. I expect there to be plenty of
> different opinions on this topic and it might be hard to figure out the
> one-size-fits-most without being to limiting.
>
>
>> * As soon as health checks check something aside from simply returning a
>>> 200 status code I'd want to be able to limit access to them
>>>
>>
>> Yep, that seems reasonable. Although depending on the level of failure,
>> you may not be able to log in to see them. Starting with just a view that
>> responds with a 200 is reasonable.
>>
>
> Sure and with limiting access I was more thinking about source IPs than
> actual logins (ie open health endpoint to the internal network from which
> the loadbalancer connects)
>
>
>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>> from time to time
>>>
>>
>> I'm open to other suggestions here, but am kind of in the same boat.
>> There may be times when you briefly want DEBUG=True in a non-public
>> deployed environment or DEBUG=False in a development environment.
>> Overloading that makes those scenarios a challenge.
>>
>
> Jupp, that is also the reason why I am in a love/hate relationship with it
> :)
>
>
>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>>> variables that leak down the whole process-tree. django-environ does
>>> support this; that said there are other options like dynaconf which also
>>> support hashicorp vault which is a massive plus imo. Just being able to
>>> utilize vault for free from every django application out there would be
>>> stellar.
>>>
>>
>> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
>> about dynaconf which does a lot of the same things. I would love to see
>> Django adopt a split between "settings" (which I see as things that don't
>> change across environments) and "configuration" (things that you set per
>> environment). I did switch to django-environ's FileAwareEnv [2] which
>> allows loading from files, but not in the yaml./toml sense. I didn't go all
>> in here because I felt like it was a more controversial stance and at the
>> end of the day, you probably still need to support environment variables
>> because many (most?) PaaS providers don't have support for files like that.
>>
>
> Yes, being able to override stuff via env variables should probably be
> always allowed. And as long as we do have a "schema" of some kind (be that
> via config.get_bool or typing annotation on a configuration object) it is
> also relatively easy to convert env variables to their correct form (ie
> boolean).
>
> With the goal of getting something merged into Django eventually, I felt
>> like environment variables were the lowest bar. We have precedence for
>> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
>> think a more full-featured library like dynaconf would make it harder to
>> push some of this upstream? Users that want to use dynaconf or goodconf or
>> whatever can still edit their settings and use those like they do today.
>>
>
> Yes and no. A 3rd party dependency will make it certainly harder to get
> this merged upstream. On the other hand I wouldn't want to support env
> variables only in the first iteration if that makes adding support for
> "properly" typed schemes (yaml/toml) harder in the future. From a viability
> point I'd like to see that we have an API that can handle hierarchical
> typed config and env variables. If we get that right the reasons to use
> something else will be rather small I guess.
>
> > Had another thought here... what about providing a pluggable
> configuration backend? Django could ship with some native backends like
> environment variables and toml (when it's available). Third party packages
> could provide Vault, secret files, etc. Same as how storages currently
> works and how you can easily drop in something like django-storages.
>
> Yes, the main question though is how the api contract would look like and
> how we are going to "solve" the chicken egg problem of how those backends
> are activated? We cannot really put `SETTING_LOADERS =
> ["django.settings.loaders.env", "django.settings.loader.toml"]` into a
> `settings.py` file and then use `config.get("DATABASE_URL")` just below to
> use the DATABASE_URL. So like `DJANGO_SETTINGS_MODULE` this would be
> something that has to be in an env var before 

Re: #21978 include production-ready web server

[Peter Baumgartner]

Hey Tobias! Not using DJANGO_SETTINGS_MODULE is due to my personal dislike
of it :)
I don't like the idea of a totally different Python file getting imported
based on an environment variable and I feel like having different Python
files for each environment isn't a great pattern. I think it is easier to
have major deviations between environments that aren't ever tested until
that environment is reached. I don't love Python being the language for
this type of configuration. I think something static like toml/yaml (or env
vars in a pinch) is easier to reason about, easier to dynamically generate,
and ultimately needs to be used if you want to avoid hard-coding secrets in
your repo.

All that being said, I realize the difference is subtle and goes against
the grain of what's already there. I'm willing to go whatever route makes
it easiest to get accepted.

On Sat, Oct 29, 2022 at 6:02 PM 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> Hi Pete,
>
> A pluggable backend sounds like a good idea.
>
> Regarding DJANGO_ENV, why not ship the template with two settings files
> and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
> environment variable?
>
> Maybe that would be controversial too, I'm not sure, but perhaps less so
> than introducing a new paradigm? In any event, perhaps a pluggable backend
> would allow everyone to be happy, or very nearly so... 
>
> To be clear, I'm fully in support of this, no matter how it ends up.
> Providing a decent production-capable server and some sane
> settings/configuration defaults for people to work from -- rather than
> having to scour the documentation for every mention of a production
> environment and figure out how to make those changes by hand -- will be a
> big win IMO. As it stands, first time users might reasonably assume they
> should use Apache to deploy to production (maybe they should, I'm not
> sure...but I haven't seen it done in over a decade):
>
> "We’ve included this with Django so you can develop things rapidly,
> without having to deal with configuring a production server – such as
> Apache – until you’re ready for production."
>
> https://docs.djangoproject.com/en/4.1/intro/tutorial01/
>
> Cheers,
> Tobias
>
> On Sat, Oct 29, 2022, 7:15 PM Peter Baumgartner 
> wrote:
>
>>
>>
>> On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
>> wrote:
>>
>>> Thanks for the thorough review Florian! Some comments inline...
>>>
>>> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
>>> wrote:
>>>
>>>> Hi Pete,
>>>>
>>>> this does look interesting. And I agree that this is something that
>>>> would be nice to have in core in one form or another. That said I think we
>>>> have to do it iteratively (ie in smaller parts) and evaluate along the way.
>>>>
>>>
>>> Agreed. I think adding the additional settings with some sort of
>>> production switch is the least obtrusive place to start.
>>>
>>>
>>>>
>>>> Since you asked for feedback, I'll tell you what I'd do differently
>>>> (and this is also a sign that production environment vary widely).
>>>>
>>>
>>> Production environments do vary widely, but I don't think that should
>>> stop us from providing defaults that are one-size-fits-most. startproject
>>> already does this and users are welcome to adjust it how they see fit.
>>>
>>>
>>>>
>>>>  * As soon as health checks check something aside from simply returning
>>>> a 200 status code I'd want to be able to limit access to them
>>>>
>>>
>>> Yep, that seems reasonable. Although depending on the level of failure,
>>> you may not be able to log in to see them. Starting with just a view that
>>> responds with a 200 is reasonable.
>>>
>>>
>>>>  * I like my dev env to be as close as possible to production so I
>>>> usually also use whitenoise in dev. I had to many times where dev worked
>>>> and whitenoise in prod failed then :D
>>>>
>>>
>>> Also a good point... I'll add that.
>>>
>>>
>>>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>>> from time to time
>>>>
>>>
>>> I'm open to other suggestions here, but am kind of in the same boat.
>>> There may be times when you briefly want DEBUG=True in a non-public
>>> deployed environment or DEBUG=False in a development envir

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
wrote:

> Thanks for the thorough review Florian! Some comments inline...
>
> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
> wrote:
>
>> Hi Pete,
>>
>> this does look interesting. And I agree that this is something that would
>> be nice to have in core in one form or another. That said I think we have
>> to do it iteratively (ie in smaller parts) and evaluate along the way.
>>
>
> Agreed. I think adding the additional settings with some sort of
> production switch is the least obtrusive place to start.
>
>
>>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>> this is also a sign that production environment vary widely).
>>
>
> Production environments do vary widely, but I don't think that should stop
> us from providing defaults that are one-size-fits-most. startproject
> already does this and users are welcome to adjust it how they see fit.
>
>
>>
>>  * As soon as health checks check something aside from simply returning a
>> 200 status code I'd want to be able to limit access to them
>>
>
> Yep, that seems reasonable. Although depending on the level of failure,
> you may not be able to log in to see them. Starting with just a view that
> responds with a 200 is reasonable.
>
>
>>  * I like my dev env to be as close as possible to production so I
>> usually also use whitenoise in dev. I had to many times where dev worked
>> and whitenoise in prod failed then :D
>>
>
> Also a good point... I'll add that.
>
>
>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>> from time to time
>>
>
> I'm open to other suggestions here, but am kind of in the same boat. There
> may be times when you briefly want DEBUG=True in a non-public deployed
> environment or DEBUG=False in a development environment. Overloading that
> makes those scenarios a challenge.
>
>
>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>> variables that leak down the whole process-tree. django-environ does
>> support this; that said there are other options like dynaconf which also
>> support hashicorp vault which is a massive plus imo. Just being able to
>> utilize vault for free from every django application out there would be
>> stellar.
>>
>
> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
> about dynaconf which does a lot of the same things. I would love to see
> Django adopt a split between "settings" (which I see as things that don't
> change across environments) and "configuration" (things that you set per
> environment). I did switch to django-environ's FileAwareEnv [2] which
> allows loading from files, but not in the yaml./toml sense. I didn't go all
> in here because I felt like it was a more controversial stance and at the
> end of the day, you probably still need to support environment variables
> because many (most?) PaaS providers don't have support for files like that.
>
> With the goal of getting something merged into Django eventually, I felt
> like environment variables were the lowest bar. We have precedence for
> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
> think a more full-featured library like dynaconf would make it harder to
> push some of this upstream? Users that want to use dynaconf or goodconf or
> whatever can still edit their settings and use those like they do today.
>
> [1] https://github.com/lincolnloop/goodconf
> [2]
> https://django-environ.readthedocs.io/en/latest/tips.html#docker-style-file-based-variables
>

Had another thought here... what about providing a pluggable configuration
backend? Django could ship with some native backends like environment
variables and toml (when it's available). Third party packages could
provide Vault, secret files, etc. Same as how storages currently works and
how you can easily drop in something like django-storages.


>
>
>>
>> Another thing about settings, and this is something I really like in
>> spring-boot is their relaxed binding for configuration variables. You can
>> look at
>> https://github.com/spring-projects/spring-boot/wiki/Relaxed-Binding-2.0
>> for an example. They describe there how hierarchical variables are handled
>> and translated between yaml and env variables. Of course this binding is
>> not exactly bidirectional always (I think) but it allows for a few nice
>> things. First off you can start with a config file in yaml (one might
>> dislike yaml but I find it easier to read 

Re: #21978 include production-ready web server

[Peter Baumgartner]

>>> mind, yes, but I'd probably not want to bundle the options for each server
>>>> myself, as that seems a lot to maintain over time... (Better to outsource
>>>> to the individual projects no?)
>>>>
>>>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>>>
>>>> https://github.com/ehmatthes/django-simple-deploy
>>>>
>>>> I really like the idea: in an opinionated way, it applies the project
>>>> changes you need to deploy (and it's plugable so folks could provide a
>>>> *template* for their own flavour of deployment if they wanted, which is
>>>> kind of important given the number of options in the landscape, even if you
>>>> only to *ship* a beginner option.)
>>>>
>>>> Tim Allen also recently raised improving the Django project template,
>>>> which I think is related here. (That's on my list too: async this QTR, then
>>>> hoping to take on Adam's proposal to modernise the Request object for the
>>>> end of year, then 爛 swinging back here for "OK, what does it look like,
>>>> what can we do?" after that: there's a bunch of related tickets around
>>>> #21978 that it would be very sweet if we could clear up...)
>>>>
>>>> I think all these thoughts are really pursuable outside of core in the
>>>> very short run, even if the goal is to merge them — it's much easier to
>>>> experiment that way, and then say, "This worked".
>>>>
>>>> Anyhow, other than a "I've been thinking along these lines", and a
>>>> generally positive emote, I don't have too much more concrete at this
>>>> stage.
>>>> 
>>>> C.
>>>>
>>>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>>>> wrote:
>>>>
>>>>> Thanks for the additional background Carlton! I like the idea of
>>>>> having some sort of protocol that folks can follow to make
>>>>> ready-to-use Django server packages (django-webserver [1] is in the
>>>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>>>> great, but getting to production with that approach can feel like
>>>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>>>> dj-database-url, etc. and it ends up being a laundry list of things
>>>>> that, in my experience, people rarely get right on the first try and
>>>>> just result in frustration.
>>>>>
>>>>> It seems like part of the challenge here is reaching parity with the
>>>>> current runserver command, but is that necessary? Running `runserver
>>>>> --dev` locally and getting dev features like autoreloading and then
>>>>> having `runserver` use a different server for a deployed app doesn't
>>>>> seem unreasonable.
>>>>>
>>>>> [1] https://github.com/lincolnloop/django-webserver
>>>>>
>>>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>>>  wrote:
>>>>> >
>>>>> > Hey Pete.
>>>>> >
>>>>> > Yes... this is a good one.
>>>>> >
>>>>> > It's difficult to see how we can even have an ASGI runserver in
>>>>> core, simply because there's no SimpleServer equivalent as there is for
>>>>> WSGI, and it's not clear one is on the card. (HTTP is getting **more**
>>>>> complex, and I can't see  Python bringing such into the standard library.)
>>>>> > So we have to use a third-party dependency for that.
>>>>> >
>>>>> > For the Channels v4 update (in progress now) I'm moving the
>>>>> runserver command to the Daphne package. This was because folks wanted to
>>>>> use Channels without the Daphne/Twisted dependency.
>>>>> >
>>>>> > See: https://github.com/django/daphne/pull/429
>>>>> >
>>>>> > tl;dr — it came out pretty clean TBH. You pip install daphne, then
>>>>> add "daphne" at the top of INSTALLED_APPS. (There's a system check to make
>>>>> sure you're not fighting staticfiles.)
>>>>> >
>>>>> > On the back of that I don't see why servers (any servers) can't
>>>>> provide a runserver command (or a django-* mini-package to go with it) and
>>>>> offer what they offer in development as well as p

Re: #21978 include production-ready web server

[Peter Baumgartner]

op.com <
>> pe...@lincolnloop.com> wrote:
>>
>>> I hadn't seen django-simple-deploy. At first glance, it looks
>>> interesting, but more platform-specific than what I was thinking.
>>>
>>> I'll play around with creating a third-party app that encapsulates some
>>> of these thoughts and see where I end up.
>>>
>>> Thanks for your time and feedback!
>>>
>>> On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6 carlton...@gmail.com
>>> wrote:
>>>
>>>> Hey Pete.
>>>>
>>>> Yes, there can be a lot of steps... (and trouble is every one has a
>>>> different opinion once you get to specifics :)
>>>>
>>>> django-webserver looks good — in a similar ballpark to what I had in
>>>> mind, yes, but I'd probably not want to bundle the options for each server
>>>> myself, as that seems a lot to maintain over time... (Better to outsource
>>>> to the individual projects no?)
>>>>
>>>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>>>
>>>> https://github.com/ehmatthes/django-simple-deploy
>>>>
>>>> I really like the idea: in an opinionated way, it applies the project
>>>> changes you need to deploy (and it's plugable so folks could provide a
>>>> *template* for their own flavour of deployment if they wanted, which is
>>>> kind of important given the number of options in the landscape, even if you
>>>> only to *ship* a beginner option.)
>>>>
>>>> Tim Allen also recently raised improving the Django project template,
>>>> which I think is related here. (That's on my list too: async this QTR, then
>>>> hoping to take on Adam's proposal to modernise the Request object for the
>>>> end of year, then 爛 swinging back here for "OK, what does it look like,
>>>> what can we do?" after that: there's a bunch of related tickets around
>>>> #21978 that it would be very sweet if we could clear up...)
>>>>
>>>> I think all these thoughts are really pursuable outside of core in the
>>>> very short run, even if the goal is to merge them — it's much easier to
>>>> experiment that way, and then say, "This worked".
>>>>
>>>> Anyhow, other than a "I've been thinking along these lines", and a
>>>> generally positive emote, I don't have too much more concrete at this
>>>> stage.
>>>> 
>>>> C.
>>>>
>>>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>>>> wrote:
>>>>
>>>>> Thanks for the additional background Carlton! I like the idea of
>>>>> having some sort of protocol that folks can follow to make
>>>>> ready-to-use Django server packages (django-webserver [1] is in the
>>>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>>>> great, but getting to production with that approach can feel like
>>>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>>>> dj-database-url, etc. and it ends up being a laundry list of things
>>>>> that, in my experience, people rarely get right on the first try and
>>>>> just result in frustration.
>>>>>
>>>>> It seems like part of the challenge here is reaching parity with the
>>>>> current runserver command, but is that necessary? Running `runserver
>>>>> --dev` locally and getting dev features like autoreloading and then
>>>>> having `runserver` use a different server for a deployed app doesn't
>>>>> seem unreasonable.
>>>>>
>>>>> [1] https://github.com/lincolnloop/django-webserver
>>>>>
>>>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>>>  wrote:
>>>>> >
>>>>> > Hey Pete.
>>>>> >
>>>>> > Yes... this is a good one.
>>>>> >
>>>>> > It's difficult to see how we can even have an ASGI runserver in
>>>>> core, simply because there's no SimpleServer equivalent as there is for
>>>>> WSGI, and it's not clear one is on the card. (HTTP is getting **more**
>>>>> complex, and I can't see  Python bringing such into the standard library.)
>>>>> > So we have to use a third-party dependency for that.
>>>>> >
>>>>> > For the Channels v4 update (in progress now)

Re: #21978 include production-ready web server

[Peter Baumgartner]

I put together a first stab at this at
https://github.com/lincolnloop/django-production. Feedback is appreciated!

On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com 
wrote:

> I hadn't seen django-simple-deploy. At first glance, it looks interesting,
> but more platform-specific than what I was thinking.
>
> I'll play around with creating a third-party app that encapsulates some of
> these thoughts and see where I end up.
>
> Thanks for your time and feedback!
>
> On Tuesday, August 23, 2022 at 1:17:12 PM UTC-6 carlton...@gmail.com
> wrote:
>
>> Hey Pete.
>>
>> Yes, there can be a lot of steps... (and trouble is every one has a
>> different opinion once you get to specifics :)
>>
>> django-webserver looks good — in a similar ballpark to what I had in
>> mind, yes, but I'd probably not want to bundle the options for each server
>> myself, as that seems a lot to maintain over time... (Better to outsource
>> to the individual projects no?)
>>
>> Have you seen what Eric Matthes is doing with django-simple-deploy?
>>
>> https://github.com/ehmatthes/django-simple-deploy
>>
>> I really like the idea: in an opinionated way, it applies the project
>> changes you need to deploy (and it's plugable so folks could provide a
>> *template* for their own flavour of deployment if they wanted, which is
>> kind of important given the number of options in the landscape, even if you
>> only to *ship* a beginner option.)
>>
>> Tim Allen also recently raised improving the Django project template,
>> which I think is related here. (That's on my list too: async this QTR, then
>> hoping to take on Adam's proposal to modernise the Request object for the
>> end of year, then 爛 swinging back here for "OK, what does it look like,
>> what can we do?" after that: there's a bunch of related tickets around
>> #21978 that it would be very sweet if we could clear up...)
>>
>> I think all these thoughts are really pursuable outside of core in the
>> very short run, even if the goal is to merge them — it's much easier to
>> experiment that way, and then say, "This worked".
>>
>> Anyhow, other than a "I've been thinking along these lines", and a
>> generally positive emote, I don't have too much more concrete at this
>> stage.
>> 
>> C.
>>
>> On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
>> wrote:
>>
>>> Thanks for the additional background Carlton! I like the idea of
>>> having some sort of protocol that folks can follow to make
>>> ready-to-use Django server packages (django-webserver [1] is in the
>>> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
>>> great, but getting to production with that approach can feel like
>>> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
>>> dj-database-url, etc. and it ends up being a laundry list of things
>>> that, in my experience, people rarely get right on the first try and
>>> just result in frustration.
>>>
>>> It seems like part of the challenge here is reaching parity with the
>>> current runserver command, but is that necessary? Running `runserver
>>> --dev` locally and getting dev features like autoreloading and then
>>> having `runserver` use a different server for a deployed app doesn't
>>> seem unreasonable.
>>>
>>> [1] https://github.com/lincolnloop/django-webserver
>>>
>>> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>>>  wrote:
>>> >
>>> > Hey Pete.
>>> >
>>> > Yes... this is a good one.
>>> >
>>> > It's difficult to see how we can even have an ASGI runserver in core,
>>> simply because there's no SimpleServer equivalent as there is for WSGI, and
>>> it's not clear one is on the card. (HTTP is getting **more** complex, and I
>>> can't see  Python bringing such into the standard library.)
>>> > So we have to use a third-party dependency for that.
>>> >
>>> > For the Channels v4 update (in progress now) I'm moving the runserver
>>> command to the Daphne package. This was because folks wanted to use
>>> Channels without the Daphne/Twisted dependency.
>>> >
>>> > See: https://github.com/django/daphne/pull/429
>>> >
>>> > tl;dr — it came out pretty clean TBH. You pip install daphne, then add
>>> "daphne" at the top of INSTALLED_APPS. (There's a system check to make sure
>>> you're not fighting staticfiles.)
>>> >
>>> > On th

Re: #21978 include production-ready web server

[Peter Baumgartner]

Thanks for the additional background Carlton! I like the idea of
having some sort of protocol that folks can follow to make
ready-to-use Django server packages (django-webserver [1] is in the
same vein), but I'd strive for more. pip install + INSTALLED_APPS is
great, but getting to production with that approach can feel like
death by a thousand paper cuts. Do that with gunicorn, whitenoise,
dj-database-url, etc. and it ends up being a laundry list of things
that, in my experience, people rarely get right on the first try and
just result in frustration.

It seems like part of the challenge here is reaching parity with the
current runserver command, but is that necessary? Running `runserver
--dev` locally and getting dev features like autoreloading and then
having `runserver` use a different server for a deployed app doesn't
seem unreasonable.

[1] https://github.com/lincolnloop/django-webserver

On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
 wrote:
>
> Hey Pete.
>
> Yes... this is a good one.
>
> It's difficult to see how we can even have an ASGI runserver in core, simply 
> because there's no SimpleServer equivalent as there is for WSGI, and it's not 
> clear one is on the card. (HTTP is getting **more** complex, and I can't see  
> Python bringing such into the standard library.)
> So we have to use a third-party dependency for that.
>
> For the Channels v4 update (in progress now) I'm moving the runserver command 
> to the Daphne package. This was because folks wanted to use Channels without 
> the Daphne/Twisted dependency.
>
> See: https://github.com/django/daphne/pull/429
>
> tl;dr — it came out pretty clean TBH. You pip install daphne, then add 
> "daphne" at the top of INSTALLED_APPS. (There's a system check to make sure 
> you're not fighting staticfiles.)
>
> On the back of that I don't see why servers (any servers) can't provide a 
> runserver command (or a django-* mini-package to go with it) and offer what 
> they offer in development as well as production. (Obviously that all needs 
> writing but it's just a management command.)
>
> Related is strategising the reloader. 
> https://code.djangoproject.com/ticket/30213
>
> We could then host *Protocols* — "Your runserver should do this", "Implement 
> this for your reloader", and so on — and (maybe) (slowly) replace built-in 
> options here with either optional dependencies (pip install django["daphne"]) 
> or recommendations to get going. (pip install django["starter"] maybe). — I 
> don't know — we seem a long way from that. (I don't suppose wsgiref is going 
> anywhere too soon is it?)
>
> But to cut back to your point, I don't know that we need to **include** a 
> server — just make it easy to get going. These days pip install + a line in 
> INSTALLED_APPS doesn't seem too much to ask (I think.)
>
> Was it really 4 years ago Tom left that comment on #21978  (We'd finally 
> close this as wontfix: Django doesn't ship a webserver.)
>
> Does that fit in your view, or would that scenario not be good enough?
>
> Kind Regards,
>
> Carlton
>
> On Tue, 23 Aug 2022 at 16:56, Peter Baumgartner  wrote:
>>
>> Hi all! I'd like to re-open the discussion around
>> https://code.djangoproject.com/ticket/21978
>>
>> As a "batteries included" framework, Django kind of leaves people to
>> fend for themselves when it comes to deployment. This makes it harder
>> than necessary for a developer to go from works-on-my-laptop to
>> works-on-the-internet. The docs here are great, but also daunting to a
>> newcomer https://docs.djangoproject.com/en/4.1/howto/deployment/
>>
>> I'd love to see Django provide some sane defaults that people can use
>> to deploy a site without having to make a bunch of decisions they
>> don't totally understand.
>>
>> I have two thoughts on how it could be handled:
>>
>> 1. Similar to the template backends. You get Django's template system
>> by default, but you're welcome to swap in Jinja2. I don't believe
>> there is a one-size-fits-all webserver, but probably a
>> one-size-fits-most.
>> 2. Similar to cache/database backends. You define the backend you want
>> to use and Django makes some sane choices for you and allows you to
>> serve the site via some common `manage.py` command.
>>
>> For the first option, Gunicorn is a popular choice, but afaik it does
>> not work on Windows. Waitress [1] is an interesting option for WSGI
>> serving and daphne exists for ASGI. Whitenoise is a reasonable choice
>> for serving static files. It doesn't yet support ASGI, but there has
>> been some activity on that front [2].
>>
>> Thanks!
>>
>>

#21978 include production-ready web server

[Peter Baumgartner]

Hi all! I'd like to re-open the discussion around
https://code.djangoproject.com/ticket/21978

As a "batteries included" framework, Django kind of leaves people to
fend for themselves when it comes to deployment. This makes it harder
than necessary for a developer to go from works-on-my-laptop to
works-on-the-internet. The docs here are great, but also daunting to a
newcomer https://docs.djangoproject.com/en/4.1/howto/deployment/

I'd love to see Django provide some sane defaults that people can use
to deploy a site without having to make a bunch of decisions they
don't totally understand.

I have two thoughts on how it could be handled:

1. Similar to the template backends. You get Django's template system
by default, but you're welcome to swap in Jinja2. I don't believe
there is a one-size-fits-all webserver, but probably a
one-size-fits-most.
2. Similar to cache/database backends. You define the backend you want
to use and Django makes some sane choices for you and allows you to
serve the site via some common `manage.py` command.

For the first option, Gunicorn is a popular choice, but afaik it does
not work on Windows. Waitress [1] is an interesting option for WSGI
serving and daphne exists for ASGI. Whitenoise is a reasonable choice
for serving static files. It doesn't yet support ASGI, but there has
been some activity on that front [2].

Thanks!

[1] https://pypi.org/project/waitress/
[2] https://github.com/evansd/whitenoise/pull/359

-- 
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/CAC6K9zk5PmcxYWXRdvco1pWXnO%2BHoYoYHf0pg5Mw%3DgmdefZArg%40mail.gmail.com.

Re: [GSoC 2020] Secrets Manager Proposal

[Peter Baumgartner]

You might find https://github.com/lincolnloop/goodconf interesting. I
see some overlap there with what you're doing.

On Mon, Mar 23, 2020 at 9:43 AM Abhirav Dilip Kariya
 wrote:
>
> Hi,
>
> Thank your for the suggestion.
>
> I did look at some libraries. However, the libraries I looked into (or  
> rather, was able to find) only dealt with single type of secrets store. Like 
> django-environ only deals with .env files.
>
> Please let me know if you have any libraries in mind.
>
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c6409dde-3390-4cc3-9769-fc4ba08b4a98%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/CAC6K9z%3D7UBUvLi%2Be%3D9Dy1NFBJ4nX3Yqy4%2Bdjxw9Jc1rjthoWiQ%40mail.gmail.com.

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

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
>> >  
>> > <https://groups.google.com/d/msgid/django-developers/b6229b20-0647-4e0a-b9e6-31136a774e13%40googlegroups.com?utm_medium=email_source=footer>.
>> >  For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message b

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: #29752 Adding a ALLOWED_HOSTS_IGNORABLE_URLS setting

[Peter Baumgartner]

I implemented something for this in the django-alive package via a
middleware that will bypass the host checking:

https://github.com/lincolnloop/django-alive/#disabling-allowed_hosts-for-healthchecks
https://github.com/lincolnloop/django-alive/blob/master/django_alive/middleware.py

On Fri, Sep 14, 2018 at 3:18 PM Adam Johnson  wrote:

> The snippet Matt posted is the same technique I've used for ages, albeit
> using the ec2-metadata  library. I
> think it's perfectly fine as-is, the Host header EC2 uses is actually
> predictable as the EC2 Private IP. I don't think Django needs another
> setting that disables a security feature and could be open to
> misconfiguration.
>
> On Fri, 14 Sep 2018 at 20:29, Mattia Procopio  wrote:
>
>> What I usually do is rewriting the Host value at webserver level using
>> one of the allowed when receiving healthchecks from a load balancer. This
>> is not optimal and having a whitelist for some uris to allow requests
>> without a valid host could make this specific thing easier
>>
>> --
>> 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/e51aa4d8-d263-4448-ab3c-d0717035fbcb%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/CAMyDDM0_uL%2B7APa%3DwgvU_GZaqO8fXDJOWAFKf0jGGB1pMVs2kg%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/CAAoxf4v_eJ-%3D%3Dpd-ZA42PLkmN2Gq_QNeHz_D%3DsunZZexVqdt5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: slow migrations

[Peter Baumgartner]

Reporting back on some additional findings for what it's worth.
SmileyChris dumped and recreated the project in question's migrations,
manually ordering them to minimize dependencies. It was not a major
reduction in total migrations: 82 to 58 (mostly third-party migrations
and initials), but the time to create an empty migration dropped
massively. It went from 260s on 1.8.6 (160s on 1.9.1) to 2s on both
versions.

I'm not sure what to make of it, but the slowness I was seeing doesn't
seem to be as much related to number of migrations, but perhaps the
contents of the migrations files. Is it possible that having lots of
cross-app migration dependencies could be the cause?

Thanks as always!

-- Pete

On Thu, Jan 7, 2016 at 3:12 PM, Carl Meyer  wrote:
> On 01/07/2016 03:03 PM, Aymeric Augustin wrote:
>> As far as I understand, the CPU cost comes from generating a full set of
>> model classes for each step of the migration history. That’s consistent
>> with the profile sent by Florian.
>>
>> I usually end up throwing away the migration history and regenerating a
>> new set of migrations when I get to that point. This requires truncating
>> the django_migrations table manually and faking the new set of migrations.
>>
>> If the project doesn’t use data migrations, squashmigrations may achieve
>> the same effect. Sadly real-life projects tend to have data migrations
>> whose only purpose is to run once in production. They prevent full
>> squashing.
>
> FWIW, I've also done a hybrid of these two options, where I generate
> fresh initial migrations rather than actually using squashmigrations
> (for the same reason, to avoid problems with data migrations), but then
> I still keep the old migrations around for a transition period and use
> the `replaces` attribute (the same one added automatically by
> `squashmigrations`) on the new initial migrations. Then later (once the
> new migrations are deployed everywhere) delete the old migrations and
> the `replaces` attr.
>
> Effectively this is similar to what you're doing, it just takes
> advantage of the `replaces` feature to avoid manually fiddling with the
> migrations table on each deployment.
>
> If I (or anyone else) ever gets around to it, I think
> https://code.djangoproject.com/ticket/24109 could make the actual
> squashmigrations command usable for real projects, by letting you just
> mark certain migrations as "please ignore when squashing".
>
> Carl
>
> --
> 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/568EE2B2.1040501%40oddbird.net.
> 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/CAAoxf4sacLi4faHx0qXuP3WF8ZXT-4nU9qcub_QGDBaHJ_em%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

[Peter Baumgartner]

It just moved. See:

http://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L924
http://code.djangoproject.com/browser/django/trunk/django/core/validators.py#L122

-- Pete

On Tue, Oct 12, 2010 at 8:44 AM, Sebastian  wrote:
> Hello,
> I investigated a bit further, it was commited with r8477
> http://code.djangoproject.com/changeset/8477
>
> But somewhere it got lost. In the current definition for SlugField I
> can only find a validation for max_length:
> http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L1000
>
> Sebastian
>
> On 12 Okt., 13:34, Luke Plant  wrote:
>> On Tue, 2010-10-12 at 04:21 -0700, Sebastian wrote:
>> > Hello,
>> > the ticket "SlugField format not enforced" is fixed, closed an "ready
>> > for checkin" since two years. What can I do?
>>
>> It is 'closed: fixed', which means the fix entered to the code base -
>> two years ago, as you say.  There is nothing left to do, so I don't see
>> what the problem is.
>>
>> Luke
>>
>> --
>> "He knows the way I take: when he has tried me, I shall come forth
>> as gold" (Job 23:10).
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Imports in the tutorial

[Peter Baumgartner]

On Fri, Jun 11, 2010 at 9:16 AM, Andrew Godwin <and...@aeracode.org> wrote:
>
>
> On 11/06/2010 03:28, Peter Baumgartner wrote:
>>
>> In my experience, almost every project has domain-specific
>> applications that don't get reused. If you have a reusable app, you
>> bundle it separately (like South).
>>
>
> I entirely agree, but there's also a lot of domain-specific apps people make
> that get used in more than one project. If you're in the business of writing
> (say) CMS-backed sites, you're going to have a lot of apps matching that
> pattern, and as far as I'm aware, there's no downside to switching away from
> having project names in imports.
>
>> Why do you need to change the Python path at all? Just drop your
>> project on the existing Python path and import from there. This is
>> easy enough with a symlink or better yet give it a setup.py and
>> install it like you would any other Python package.
>>
>
> But that doesn't work. Say I have my nice shiny project "andrewblog". I want
> to deploy a staging version and a live version of this on my server.
>
> If I had local imports, I could just put both projects on the python path /
> install them / egg-link them, or whatever. But because they use module names
> for imports, if I install one site as a package "andrewblog" and the other
> as "andrewblog_staging", say, staging is actually going to be running off of
> the live models, URLs, etc, since it has code that goes "from
> andrewblog.posts.models import Post".

Why do your two sites need to share the same python path? Virtualenv
solves this problem quite gracefully.

-- Pete

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Imports in the tutorial

[Peter Baumgartner]

On Thu, Jun 10, 2010 at 11:21 AM, Andrew Godwin  wrote:
> Hi all,
>
> I noticed today that the tutorial still does imports like "from
> mysite.polls.models import Poll", and URLs like "(r'^polls/$',
> 'mysite.polls.views.index')".
>
> At least in the places and projects I've worked with, the standard has been
> not to use the project name as part of the import, for various reasons:
>
>  - It makes apps more reuseable and not tied to the one project

In my experience, almost every project has domain-specific
applications that don't get reused. If you have a reusable app, you
bundle it separately (like South).

>  - It means you can't run two copies of the same application if they're
> direct neighbours (as, to get the imports running, you need to add the
> directory the project is contained in to the Python path, and thus you can't
> rename the directory from its import name).

Why do you need to change the Python path at all? Just drop your
project on the existing Python path and import from there. This is
easy enough with a symlink or better yet give it a setup.py and
install it like you would any other Python package.

>
> I realise both of these can be worked around (and I do a lot), but it would
> seem common sense to start encouraging people to do imports like "from
> polls.models import Poll" from day one. There might well be something I'm
> missing - please say - but this has bugged me for ages.
>

I agree that it is confusing that it will work either way, but I'd
argue in favor of using the project name everywhere. It is explicit
instead of mucking around with the Python path behind the scenes.

-- Pete

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[Peter Baumgartner]

On Mon, Apr 19, 2010 at 8:19 AM, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>

Jacob, I really think you're hearing from the vocal minority here.
There are plenty of people, myself included, who are very happy with
Django and the current development process. It will never be a perfect
fit for everyone and some will always complain. We've been using
Django professionally for a few years now and it has grown by leaps
and bounds in that time. I'm glad to see that Django is picky about
what is included. Stable growth trumps a kitchen sink worth of
half-baked features any day.

Keep up the amazing work and don't let the naysayers get you down.

-- Pete

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: contrib.admindocs need some love.

[Peter Baumgartner]

On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly  wrote:
> Hey guys.
>
>  I started writing some docs for another developer today and hit a few
> issues with admindocs that I plan on sprinting on for DjangoCon. I'm
> hoping anyone else with complaints / ideas will voice up, though my main
> impetus for the post is to announce that I'm going to do it so I
> can't back out. ;)
>
> Things I plan to address:
>
> 1. No tests.
> 2. No docs.
> 3. You can't seem to cross-link to views without the link being
> app.package.func . I'd like to see it at least configurable.
> 4. ManyToManyFields don't show up.
>
> There's not a ton there, but worth sprinting on, imo. Any other ideas or
> changes you'd like to see in admindocs that I might be able to work on?
> Shout them out.
>

It may be out of your scope, but admindocs flat-out breaks with GIS
fields. http://code.djangoproject.com/ticket/7977

-- Pete

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

ticket 3511 backwards incompatible

[Peter Baumgartner]

http://code.djangoproject.com/ticket/3511 broke some code I had that
caught AssertionError in the past. Seems like it should be listed on
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

-- 
Pete

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: somebody to review ticket #5247

[Peter Baumgartner]

>
> I've done so rather briefly, comments on the ticket.
>

Ugh, I think I was asleep at the wheel there.

I've uploaded a better patch. If you have time, please take a look.
http://code.djangoproject.com/ticket/5247

Thanks!

-- 
Pete

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

somebody to review ticket #5247

[Peter Baumgartner]

Can somebody take a look at
http://code.djangoproject.com/attachment/ticket/5247/

I updated the existing patch to work with current svn, but I'm not
familiar enough with the internals to be sure it isn't breaking things
elsewhere.

Thanks!

-- 
Pete

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Boulder, CO Sprinters

[Peter Baumgartner]

If any of you keep an eye on this list, give me a shout. I may be on
the Front Range this weekend and would like to participate.

-- 
Pete

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---