Re: Makemigrations hooks for third-party apps?

[charettes]

Hello Craig,

There's unfortunately no way to hook into the migration auto-detector to 
specify
additional operations to be added.

What I suggest you do instead is dynamically inject operations in the plan 
that
is about to be run by connecting a pre_migrate signal. When you detect
CreateModel operations for subclasses of your AbtractModel you could insert
operations to be performed before and after them. This is pattern we use
internally to perform ContentType rename on RenameModel operations[0].

As for the makemigrations hooks I think it would require a lot of thought 
and
efforts to get right. Right now the auto-detector is a black box that deals 
with
dependencies and model state deltas resolution.

In an ideal world model/fields objects would be able to generate the list of
operations they require to move from state A to B as a public API and the
auto-detector would simply iterate over the existing migrations state 
models and
compare them against the current state of the project.

Best,
Simon

[0] 
https://github.com/django/django/blob/525dc283a68c0d47f5eb2192cc4a20111d561ae0/django/contrib/contenttypes/management/__init__.py#L45-L84

Le mardi 6 juin 2017 16:45:05 UTC-4, Craig de Stigter a écrit :
>
> Hi there
>
> I'm in the early stages of developing a third party app which makes heavy 
> use of postgres extensions. The app provides an abstract model, so I won't 
> have direct control of user's models or migrations. I'm having trouble 
> getting it to generate sensible migrations for users.
>
> At present the migration process for users is going to be "copy and paste 
> my migration file template into your project, and change the model names to 
> match your app". As far as I can tell there is no way to generate 
> migrations with anything custom.
>
> The operations I need to generate are:
>
>- CreateExtension()
>- RunSQL() - (to create slightly non-standard constraints)
>
> e.g. perhaps my model could supply a couple of methods:
>
>- Model.Meta.pre_creation_operations() - returns a list of operations 
>to apply before the auto-detected model operations, e.g. creating 
>extensions etc
>- Model.Meta.post_creation_operations() - the same but applied after 
>the auto-detected operations, e.g. adding constraints/indexes.
>
> I'm envisaging that the operations returned from both methods would be 
> deconstructed and copied into migration files when makemigrations is run.
>
> Has there been any discussion about this previously? I haven't found any.
>
> Thanks
> Craig de Stigter
>

-- 
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/a152a3df-5bac-4aaa-8103-fb85194e78c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Makemigrations hooks for third-party apps?

[Craig de Stigter]

Hi there

I'm in the early stages of developing a third party app which makes heavy
use of postgres extensions. The app provides an abstract model, so I won't
have direct control of user's models or migrations. I'm having trouble
getting it to generate sensible migrations for users.

At present the migration process for users is going to be "copy and paste
my migration file template into your project, and change the model names to
match your app". As far as I can tell there is no way to generate
migrations with anything custom.

The operations I need to generate are:

   - CreateExtension()
   - RunSQL() - (to create slightly non-standard constraints)

e.g. perhaps my model could supply a couple of methods:

   - Model.Meta.pre_creation_operations() - returns a list of operations to
   apply before the auto-detected model operations, e.g. creating extensions
   etc
   - Model.Meta.post_creation_operations() - the same but applied after the
   auto-detected operations, e.g. adding constraints/indexes.

I'm envisaging that the operations returned from both methods would be
deconstructed and copied into migration files when makemigrations is run.

Has there been any discussion about this previously? I haven't found any.

Thanks
Craig de Stigter

-- 
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/CANv5zmWUsfEWpqUWh6He0mMgnt3Pen-oKq%3Dw0wghPzwwtgWWyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Jamesie Pic]

I was just thinking that changing the js widget would not require to
rewrite the python code, barely the js widget support. I'm not trying
to push it, just make sure we are taking the right facts into
consideration, but I'm happy with select2 myself.

-- 
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/CAC6Op19phT4US3Un0uQP3_2nnqzM7msizV7LfzBEYfizNqYdtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Florian Apolloner]

On Tuesday, June 6, 2017 at 11:54:16 AM UTC+2, Johannes Hoppe wrote:
>
> I think we made some good progress in the regarding this issue. The 
> inclusion of select2 is at a stage where I wouldn't want to jump to a 
> different library. Especially considering that now one acted at this ticket 
> for seven years and it took me 2 years to work on the issue and it still 
> isn't merged.
>

Absolutely, changing select2 to something different is a nogo. 

-- 
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/b99de1b4-82e3-42f3-9bbd-6f2fb2594f1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

NUMERIC with unlimited precision not supported (#24920)

[Maciej Gol]

Currently, the DecimalField does not support unlimited precision numeric 
fields that are available in db backends. As in the ticket's description 
and comments https://code.djangoproject.com/ticket/24920 , there were two 
solution proposed: new field, or an update to DecimalField's behavior. I 
wanted to start contributing to Django, and thought that adding this 
feature could be a great way of getting to know Django's code. I was also 
thinking about a way of solving this - perhaps allowing DecimalField's 
max_digits and decimal_places to be None. If so, the field translates to an 
unlimited-precision NUMERIC field. Does it sound like a way to go?

Best,
Maciej

-- 
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/6ec512c0-9a4d-4af3-a09d-76350a081b90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Jamesie Pic]

Thanks for asking, my name is ∞, but you've known my as James Pic /
YourLabs. Nice to speak with you again <3

I think it would make sense for a core dev to advocate against this
change, because we'd be breaking BC before having enough information
to know if this is going to have a generally more positive than
negative impact, I wouldn't be able to tell without trying it myself
with a community for a couple of years, and have the opportunity to
try it out with a bunch of app/widget combinations, because the Django
ecosystem (at least, the part I rely on and love) is so huge :D

Best
<3

-- 
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/CAC6Op1_AjF8xMnbi7ym8Ceu45oDeiR8woaN-0K_4PZmzYT0CrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Johannes Hoppe]

Hi!

I didn't get your name, but this address the latest post.

I think we made some good progress in the regarding this issue. The 
inclusion of select2 is at a stage where I wouldn't want to jump to a 
different library. Especially considering that now one acted at this ticket 
for seven years and it took me 2 years to work on the issue and it still 
isn't merged.

That being said, the major question remaining is whether or not to disable 
`noConflict(true)`. I don't mind, I made it work without it. But 
maintenance wise, it's simpler to just disable it.

I would love to see some feedback from the core team here. I really like to 
get this resolved.

Cheers
-Johannes

On Tuesday, June 6, 2017 at 9:36:04 AM UTC+2, is_null wrote:
>
> Hi all,
>
> In our experience, it would be worth removing noConflict, but we need 
> Django to have a recent jQuery release, it's wasn't always the case but now 
> it's good. I don't know who relies on that except grappeli, but they would 
> probably be happy to get rid of their double jquery loading because that's 
> been the source of many user issues, at least in DAL's repo.
>
> Another library that would be worth proposing is jquery-autocomplete-light 
> (disclamer: I'm the author), particularely because it is built to let the 
> server render the suggestions box, and because it's pretty light by essence 
> (does nothing on selection but trigger an event, it's up to the developer 
> to implement the callback). But I should do some crowdfunding or something 
> to cover it with JS unit tests, currently it's abandoned except by most 
> django-autocomplete-light < 3.0 users, some v3 users are using it already 
> even thought it's not been officially released / supported, because I was 
> maintaining it with selenium tests and that was too much of a pain of 
> course to have no unit tests.
>
> If you need generic form widgets, I think we've got ok ones in 
> django-autocomplete-light v3. Again what's missing for developer experience 
> is just the ability to override the default form, without having to 
> subclass the world just to pass it: when you need an autocomplete on a 
> field, you most likely need it everywhere, ie. because the select would 
> load too many options to be usable.
>
> We'd be very happy to see noConflict removed, and try to all rely on the 
> latest jQuery, rather than all try to load our own and deal with different 
> variables names for jQuery. Perhaps I should try this in a fork, even if 
> that means DAL will require extra steps for users not on that specific 
> Django fork, at least we'd figure out if removing noConflict had unseen 
> drawbacks.
>
> Best
>

-- 
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/076f436b-1c02-49c7-b174-d400b3b1ec9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[is_null]

Hi all,

In our experience, it would be worth removing noConflict, but we need 
Django to have a recent jQuery release, it's wasn't always the case but now 
it's good. I don't know who relies on that except grappeli, but they would 
probably be happy to get rid of their double jquery loading because that's 
been the source of many user issues, at least in DAL's repo.

Another library that would be worth proposing is jquery-autocomplete-light 
(disclamer: I'm the author), particularely because it is built to let the 
server render the suggestions box, and because it's pretty light by essence 
(does nothing on selection but trigger an event, it's up to the developer 
to implement the callback). But I should do some crowdfunding or something 
to cover it with JS unit tests, currently it's abandoned except by most 
django-autocomplete-light < 3.0 users, some v3 users are using it already 
even thought it's not been officially released / supported, because I was 
maintaining it with selenium tests and that was too much of a pain of 
course to have no unit tests.

If you need generic form widgets, I think we've got ok ones in 
django-autocomplete-light v3. Again what's missing for developer experience 
is just the ability to override the default form, without having to 
subclass the world just to pass it: when you need an autocomplete on a 
field, you most likely need it everywhere, ie. because the select would 
load too many options to be usable.

We'd be very happy to see noConflict removed, and try to all rely on the 
latest jQuery, rather than all try to load our own and deal with different 
variables names for jQuery. Perhaps I should try this in a fork, even if 
that means DAL will require extra steps for users not on that specific 
Django fork, at least we'd figure out if removing noConflict had unseen 
drawbacks.

Best

-- 
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/43f81fe5-6999-4400-90a7-68585ca51c49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Activity Reports

[Angelo Dini]

Hello John

Thanks for your feedback. Our plan was to develop migration paths to these 
addons as we (Divio) won't actively maintain these addons anymore. If 
someone steps forward and does so, we could talk about commit rights. But 
as it is with open-source, we've no deadline on the migration path. We're 
currently heavily involved into various projects and had so far no client 
who wished to migrate.

I'm currently not aware of any changes that might break cmsplugin-filer but 
that can change of course, also with the introduction of Django 1.11 and/or 
other package updates. The new plugins are though production ready (and 
also used on live instances). The most consuming part of the migration is 
to write a management script to migrate the data and test it.

On Sunday, 4 June 2017 07:11:28 UTC+2, John-Scott wrote:
>
> Hi Angelo,
>
> I may have misunderstood the roadmap for core addons 
> :
>
> Deprecated addons
>> Some older plugins that you may have encountered are now deprecated and 
>> we advise against incorporating them into new projects.
>> These are: 
>>
>>- cmsplugin filer 
>>
>>
>>- Aldryn Style 
>>
>>
>>- Aldryn Locations 
>>
>>
>>- Aldryn Snippet 
>>
>> We'll be developing migration paths to help users who have these 
>> installed in their projects move to newer, official core addons that 
>> provide the same functionality.
>
>
> I thought that meant *Divio* made the decision to deprecate 
> cmsplugin-filer and would be developing migration paths. I haven't seen any 
> discussion on this list regarding this change, the blog is the only source 
> of details I've seen. It looks like cmsplugin-filer development stopped 
> last fall, but the README has not been updated to warn people away from 
> using it in new projects so it's not clear if it is 'officially' deprecated 
> or not.
>
> Are there any known upcoming changes in django-cms that will break 
> compatibility with cmsplugin-filer? Will pull requests/issues for 
> cmsplugin-filer be ignored going forward? Are the new favored plugins 
> production ready? A quick glance at the djangocms-picture README suggests 
> that beyond needing to do some sort of data migration, users would 
> potentially need to also update templates, settings, etc. Any other known 
> hurdles that will need to be addressed when paving the migration path?
>
> Happy to help test any proposed migration path of course! 
>
> Thanks,
> John-Scott
>
>
> On Thursday, May 25, 2017 at 11:31:41 PM UTC-7, Angelo Dini wrote:
>>
>> Hello John,
>>
>> that is no Problem. It is still on our todo lists but we are a bit 
>> consumed from projects/client work. I can't really give an 
>> estimate/deadline as it's an open-source effort. I'm also very happy if 
>> someone could help or tackle the task.
>> I'd announce it here or via Blog if I'll get to anything.
>>
>> Cheers
>> Angelo
>>
>> On Thursday, 25 May 2017 21:29:29 UTC+2, John-Scott wrote:
>>>
>>> Hi Angelo,
>>>
>>> Just checking back in to see what the latest thinking is on replacing 
>>> the cmsplugin_filer_* plugins as far as deprecation timeline and possible 
>>> paths for migrating to the newer djangocms-* plugins? 
>>>
>>> I haven't followed development on the new plugins closely so apologies 
>>> if this has been answered/solved elsewhere.
>>>
>>> Thanks!
>>> John-Scott
>>>
>>> On Sunday, September 11, 2016 at 11:25:03 PM UTC-7, Angelo Dini wrote:

 Hello @john

 Yes we want to replace cmsplugin-filer with more specific plugins 
 following the Python Zen "Do one thing, and that good". For that matter we 
 are working on cleanup/improving some existing plugins to replace 
 cmsplugin-filer:

 - cmsplugin_filer_file > djangocms-file
 - cmsplugin_filer_folder > djangocms-file
 - cmsplugin_filer_image > djangocms-picture
 - cmsplugin_filer_link > djangocms-link
 - cmsplugin_filer_teaser > djangocms-teaser (though we do not update it 
 for now)
 - cmsplugin_filer_video > djangocms-video

 This will mainly help us ship djangocms-installer and the default 
 installation on Aldryn with good and clean base plugins. Next step will be 
 to provide facilities to migrate older projects to these new plugins. 
 After 
 that we will deprecate the old ones (will take some months though). We 
 will 
 publish blog posts prior to this scenario :)



-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an