Re: Discussing improvements of django.setup()

[Pkl]

hello,

AppConfig could provide hooks, but it'd indeed be already quite late in the 
setup process : settings are already loaded, logging already configured, 
script prefix already set, and just accessing AppConfig could already 
trigger the import of advanced submodules (models etc.), which could break 
the early setup.

I guess an environment variable, or a naming convention, could allow early 
hooks similar to those of Gunicorn for example, and unrelated to installed 
apps.

regards,
Pascal Chambon


On Tuesday, July 2, 2019 at 8:40:04 PM UTC+2, Christian González wrote:
>
>
> Am 01.07.19 um 23:24 schrieb Pkl: 
> > 
> > Regarding django.setup() tweakability, the generic need is simply to 
> > have a hook, somewhere for users to put early init code, regardless of 
> > the way django is launched. Code that needs to execute this early are 
> > mostly (if not all) monkey-patching the environnement, a little like a 
> > LD_PRELOAD logic python-style. 
> > [snip] 
> > There are surely lots of ways to provide such a hook, via new 
> > settings, or new environment variables, or modules following precise 
> > naming conventions that django would systematically try to import... I 
> > have no idea how exactly my approach is rated amongst them. 
> > 
> > As for alternatives to these early setup hooks, I'm alas clueless... 
>
> Why not a setup() method in the Apps' AppConfig, like ready()? This way 
> the AppConfig would be used more. Problem here is: when setup runs, it 
> is loading the settings. And THERE INSTALLED_APPS first time tell Django 
> which apps are installed. So before that point, it's not possible to  
> "import modules from apps following a precise naming convention" etc. Or 
> did you mean "modules" outside of apps like e.g. a 
> "django_hook_setup_foo" python module? (Grr.) 
>
> Maybe here could again help to extract the apps list out of settings, 
> and use a descriptive list that is parsed VERY early in the setup 
> process. Then the hook could be placed (with imports from all apps). 
>
> This would help improving my GDAPS plugins system as well, instead of 
> hacking myself into INSTALLED_APPS within settings.py. 
>
> Just my 2 cents. 
>
> Christian 
>
>

-- 
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/7a34d34c-0098-4430-b9af-2bf05244755d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for a new DEP on long-term Django API compatibility

[Pkl]

Hello everyone,


(apologies in advance for the long post, but there are lots of aspects to 
dig here, it's not for the pleasure of writing but a necessary to progress 
on the relevance of a DEP)

*"As you can see, there's more than "blinding self-absorption" and "harmful 
psychological bias" here. Your freecodecamp article makes valid points. It 
also misses completely what's hard in maintaining backwards compatibility. 
I wish you hadn't found it useful to insult the work put into managing 
backwards-compatibility over the years and the people who did it."*

I'd rather address that immediately: as you read in my article, "blinding 
self-absorption", "harmful psychological bias" and other strong words were 
all aimed at something very specific, the "feeling of return to purity" 
that a person could have when destroying compatibility shims. I persist and 
sign regarding this one: ruining the day of thousands of anonymous 
plugin/website maintainers all over the world should *always* be made under 
compulsion of heavy constraints, and with regrets; never lightheartedly. 

Now, maybe my attempt at explaining the roots of nowadays' mass breakages 
by a cultural problem are all wrong (my bad), and there are other reasons 
behind the *apparently* reckless compatibility destructions that I witness 
left and right. But what are they? Since it's not technical inability, 
since it's not laziness, since it's not ideology, what makes that (as far 
as I'm concerned) the Django ecosystem fails on that aspect, contrary to 
loads of others "big" frameworks, runtimes, libraries etc? 

If it's "we don't have enough resources", it's all understandable, but at 
least let's make it clear. The weirdest, in the whole story, is the global 
idea that everything is fine, that compatibility is already a "major 
concern" and treated so, that maybe it can be improved a little bit but no 
need to push it. It's not that way I see it. And a problem can't be 
addressed if it's not first recognized as so.

Now, I know that it requires a good amount of diplomacy to criticize a 
behaviour, or here a whole policy, without concerned people feeling 
attacked. I don't have this kind of talent (and probably won't ever), so 
all I can do is be honest with my view on the situation, and bring attempts 
at solutions. It's precisely because Django is a great piece of software 
(with its omnipresent lazy-objects, it's automatic admin and model forms, 
its migration system, its focus on security headers...) that having it 
scarifying itself is unbearable. So I apologize in advance for all the 
criticisms that expand below, but without them there'd be no need for any 
DEP or change in the first place.

I also want to make this clear: I didn't mean that breaking changes were 
never justified, just that they had to be the last option, and thoroughly 
explained. When the AngularJS team, after the years of hype, admitted that 
the whole designed was flawed, reset the whole framework as Angular version 
2, and made great efforts to ease part-by-part migration towards the new 
behaviour, I felt unlucky but not angry. When trivial changes ruined tons 
of pluggable Django apps that did one thing and did it well, it was a 
different matter.

Before answering remarks, I think it's worth summarizing what the "problem" 
is. This is not lightly that I used the words "dependency hell". My 
experience with Django, purely regarding compatibility, has been abysmal 
compared to lots of other ecosystems (in C/C++, PHP, Jquery...) that I have 
crossed, and which didn't have the malleability of Python; I see several 
cumulated reasons explaining that :

- The pace of breakages: an arm's long list of new breaking changes 
introduced every 8 months, dropping at the same time all shims older than 
2-3 years, is imo a too fast breakage pace, even by the Web's standard. 
When changes are mainly aesthetical, compatibility shims had better remain 
for very long periods of time, else the benefit/harm balance is just 
indefensible.
- More importantly, the *scope* of breakages: as long as it's only about 
fixing corner cases of the framework, and only a tiny portion of users is 
impacted (those who abused counter-intuitive and unpythonic behaviours), 
one can understand, and just hope not to be shot by the next upgrade; but 
here, we're dealing with changes that deliberately break about every 
existing application, even those which scrupulously followed official 
tutorials: ForeignKey's "on_delete" argument killed most migration files 
when becoming mandatory, moving url-related primitives left and right was 
as destructive as expected...
- The growing "less batteries included" philosophy. Valueable contrib 
modules were outsourced from the codebase, and other pluggable applications 
(likes CMS apps) follow this trend, putting all valuable features into 
external plugins. This "minimal core" philosophy would work fine if main 
applications counter-balanced it with a more delicate ap

CommandTemplate Behavior Is Inconsistent

[John Gooding]

To be clear, I am not saying there is a bug. It does what it is programmed 
to do. I am saying the expected behavior of the API / CLI / whatever you 
want to call it is inconsistent.

I am not going to get into an argument of what a "proper" django structure 
is, etc. I want to focus purely on the behavior of the command.

A more "normal" setup might look like this:

/repository
  manage.py
  /project
settings.py
urls.py
etc..
  /polls
models.py
etc...

When you run `python manage.py startapp polls` from the same directory as 
manage.py, it will create the polls directory for you, normal expected 
behavior.

Another, equally as valid setup looks like this:

repository/
  manage.py
  /project
settings.py
urls.py
etc...
/polls
  models.py
  etc...
/my_app_2
  models.py
  etc...

Where all of the apps live in the project directory, or perhaps some other 
directory. Now if you try to execute `python manage.py startapp polls 
project`, it will complain that the directory doesn't exist and that you 
need to create it first. However if you `cd` into /project, and run `python 
../manage.py startapp polls`, it will create the directory for you, even 
though it doesn't exist.

My ultimate point is this, the behavior of the command should not depend on 
where it is ran. It should only care if the directory already exists or 
not, which it does check, but the applied behavior of that check is 
different depending on if you're in the line 68 if block 

 or 
the line 76 else block 
.
 
The applied behavior ought to be the same, regardless of where the command 
is ran from. 

-- 
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/dfe324ce-3718-4379-b20e-a2703973869c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.