Обсуждение: [PATCH] pglister: Add possibility to override settings.py in settings_local.py

Поиск
Список
Период
Сортировка

[PATCH] pglister: Add possibility to override settings.py in settings_local.py

От
Célestin Matte
Дата:
Following the model of pgweb and pgarchives

-- 
Célestin Matte
Вложения

Re: [PATCH] pglister: Add possibility to override settings.py in settings_local.py

От
Magnus Hagander
Дата:


On Wed, Oct 27, 2021 at 4:02 PM Célestin Matte <celestin.matte@cmatte.me> wrote:
Following the model of pgweb and pgarchives

Hi!

local_settings.py is already ignored in web/pglister/.gitignore -- does that not work for some reason? It works fine from here.

Second, I'm not sure why we want to exclude local_settings.py from pycodestyle in general?

And finally, settings.py already contains:
try:
    from .local_settings import *
except ImportError:
    pass


Just a couple of lines above where you are adding it back again. Is that also for some reason not working?

And it is important that it is included before we do the exim part for example -- otherwise you cannot control that from within local_settings.py.
 
--

Re: [PATCH] pglister: Add possibility to override settings.py in settings_local.py

От
Célestin Matte
Дата:
Hello,

> 
> And finally, settings.py already contains:
> try:
>     from .local_settings import *
> except ImportError:
>     pass
> 
> 
> Just a couple of lines above where you are adding it back again. Is that also for some reason not working?

Right, I missed that. It's just that in pgweb and pgarchives, the file is called settings_local.py, whereas pglister
callsit local_settings.py. This is just a question of naming consistency, then. Do you think it's worth patching?
 

> Second, I'm not sure why we want to exclude local_settings.py from pycodestyle in general?

It's ignored in pgweb, I just assumed there was a good reason for that and did the same thing for consistency.

Cheers,
-- 
Célestin Matte



Re: [PATCH] pglister: Add possibility to override settings.py in settings_local.py

От
Magnus Hagander
Дата:


On Sun, Oct 31, 2021 at 7:02 PM Célestin Matte <celestin.matte@cmatte.me> wrote:
Hello,

>
> And finally, settings.py already contains:
> try:
>     from .local_settings import *
> except ImportError:
>     pass
>
>
> Just a couple of lines above where you are adding it back again. Is that also for some reason not working?

Right, I missed that. It's just that in pgweb and pgarchives, the file is called settings_local.py, whereas pglister calls it local_settings.py. This is just a question of naming consistency, then. Do you think it's worth patching?

If anything, we'd want to move to local_settings.py in that case -- the reason we switched to doing that in a bunch of the other projects is TBH something as simple as "then tab completion works better".

In general we've said it's not worth breaking compat for it on the old repos though. That can obviously be argued. But if we do, we definitely don't want to do *both*, in that case we should remove them.

 
> Second, I'm not sure why we want to exclude local_settings.py from pycodestyle in general?

It's ignored in pgweb, I just assumed there was a good reason for that and did the same thing for consistency.

Oh, I wasn't even aware of that. TBH, I'm not sure that's intentional, that may be a leak from "it was easiest to do that in the beginning".

I don't really see a reason why we wouldn't want that file to be scanned as well -- do you? 

--

Re: [PATCH] pglister: Add possibility to override settings.py in settings_local.py

От
Célestin Matte
Дата:
> If anything, we'd want to move to local_settings.py in that case -- the reason we switched to doing that in a bunch
ofthe other projects is TBH something as simple as "then tab completion works better".
 
> 
> In general we've said it's not worth breaking compat for it on the old repos though. That can obviously be argued.
Butif we do, we definitely don't want to do *both*, in that case we should remove them.
 

Hrm, so what's your decision on this?

> I don't really see a reason why we wouldn't want that file to be scanned as well -- do you? 

I guess there is no real point scanning a file for proper style if it's not going to get committed

-- 
Célestin Matte