Hi, just noted this discussion...
On Sun, Jan 12, 2020 at 9:42 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello
> I created a PR for this: https://github.com/django/django/pull/12310
>
> I'd love to get some feedback on the design before I polish the patch.
>
I've left a c
Hello Christian,
Regarding your first point, adding "default = True" to 1% of apps in a
non-empty file seems better than adding default_app_config =
"foo.apps.FooConfig" to 99% of apps in an otherwise empty file (usually). You
can see the effect in
https://github.com/django/django/pull/12310/c
Oh, sorry, I just saw that this is discussed (andanswered) in the PR.
Am 13.01.20 um 23:03 schrieb Christian González:
>
> Eh, sorry if I misunderstand - but adding a "default = true" line to
> an AppConfig is the same as addign default_app_config =
> "foo.apps.FooConfig".
>
> A few things that ca
Eh, sorry if I misunderstand - but adding a "default = true" line to an
AppConfig is the same as addign default_app_config = "foo.apps.FooConfig".
A few things that came to my mind when reading the code:
* You check if there is only one AppConfig available
(https://github.com/django/django/pull/1
Hello,
I created a PR for this: https://github.com/django/django/pull/12310
I'd love to get some feedback on the design before I polish the patch.
Best regards,
--
Aymeric.
> On 10 Jan 2020, at 14:18, Christian González
> wrote:
>
>
>
> Am 08.01.20 um 22:39 schrieb Aymeric Augustin:
>>
Am 08.01.20 um 22:39 schrieb Aymeric Augustin:
The original intent was to make configuration explicit by having
settings.py reference directly the target AppConfig class.
- When you write MIDDLEWARE = ["polls"], do you expect Django to
enable "polls.middleware.PollsMiddleware"?
- When you wri
Hello Christian,
> On 5 Jan 2020, at 14:30, Christian González
> wrote:
>
> And to be honest - does this really make sense to urge people - writing more
> code to satisfy the framework?
> What I mean is: Why don't you drop that recommendation - when noone is using
> it - more than one AppConf
how to use oracle in django
On Sun, Jan 5, 2020 at 5:30 AM Christian González <
christian.gonza...@nerdocs.at> wrote:
>
> Am 20.06.19 um 03:18 schrieb Curtis Maloney:
>
>
> And a second question: The DJango docs say, that it's not recommended to
> use "default_app_config". But in each and every e
Am 20.06.19 um 03:18 schrieb Curtis Maloney:
>
>> And a second question: The DJango docs say, that it's not recommended
>> to use "default_app_config". But in each and every example, even in
>> the tutorials and the Django boilerplate code of "./manage.py
>> startproject foo" are NO Appconfigs add
On 6/20/19 7:12 AM, Christian González wrote:
What I need for a good plugin life cycle are methods, callbacks that are
called when a plugin is "installed" = run the first time, methods for
enabling/disabling etc.
>
The easiest way would be implementing these methods within the AppConfig
subcla
I'd like to ask another question concerning plugin apps, and hoping your
deeper knowledge about Django internals helps here...
I'm implementing the plugin Metadata for GDAPS plugins ATM, and am a bit
concerned wether to implement a construct like the Pretix system or not.
Pretix uses
a settings.cfg or pluginspec.cfg file to parse. You
have to trust the plugin anyway when you run it's main entry point later.
And from that POV, using Python code (= a class) as metadata or
settings, is ok, so most certainly I will implement Pretix' Metadata
system into GDAPS as wel
ause Django works this way. I don't recommend Django to
completely change its way of loading apps.
In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to
INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via
setuptools entry point, like pretix. I therefore added my
That's because Django works this way. I don't recommend Django to
completely change its way of loading apps.
In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to
INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via
setuptools entry point, like pretix. I therefore added
Long time lurker first time poster; could this possibly be addressed with
something along the lines of SECRET_KEY? It seems to me that no more of a
namespace would be needed than a uniquely identifying hash per app/module. Not
so much in settings or app_config as __init__, maybe?
Hi,
Benny
> O
[forgive me for typing as I think... but sometimes it's the best way to
think ;) ]
On 6/17/19 5:19 AM, Christian González wrote:
Am 16.06.19 um 10:06 schrieb Adam Johnson:
* What do you think are the implications for Django core? Is there
anything Django could do better to support this and all
h him
a while ago about that and he was the one who I learned a lot from about
how to create GDAPS. Basically my implementation does not differ too
much, and I even am considering using his "PretixPluginMeta" inner class
in the AppConfig of GDAPS plugins too. I just think about other way
Hi Christian,
Welcome to the django developers list. I have had a quick look over GDAPS
and have some comments and questions back for you:
* Your “homepage” link on PyPI is example.com. The usual thing to do here
is link to your source host or docs. Set this as url in your setup.py.
* I see you
hed "Alpha state" for GDAPS - my "Generic
Django Apps Plugin System" which is an "enhancement" of Django's app
system, enabling Django to create "pluggable", extendable applications
with ease.
Just have a look at https://pypi.org/project/gdaps/
Thought
19 matches
Mail list logo
