Check if dependencies are up to date

[mathieu.tortuyaux]

Hello everyone, 

I would propose this new Django feature. Now you can check if your dependencies are up-to-date (e.g with `hypothesis` in attachment picture) (it runs with Python2.7 && Python3.6).

It is a good habit to check if dependencies are up-to-date, especially for security reasons. 

I did not find any references about this in Django issues

So I wondering if I can have any feedback on this ?

Thank you for taking time to read these words. 

Mathieu Tortuyaux

[Adam Johnson]

Hi Mathieu,

We implemented something similar at YPlan but discovered that it wasn't a good idea as a system check, because if a dependency changes from another devs work then often Django can't even start and run the system check. Especially a problem when upgrading Django itself! Instead we implemented it as a function that runs in manage.py before Django is even loaded.

We open sourced our work as https://github.com/YPlan/pip-lock . Check it out.

--


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-develop...@googlegroups.com.


To post to this group, send email to django-d...@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/5a6fb42e-e5c8-4608-9b20-19fc829473b1%40googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

[Dmitry Gladkov]

Hello,

While I was reading this email I got an idea about generic Django command signals that might be useful for extending command functionality without subclassing the Command class and relying on INSTALLED_APPS order. Something like this:

from django.core.management.signals import pre_command, post_command

def handle_pre(sender, instance):

    instance.stdout.write('Hello World')

def handle_post(sender, instance):

    instance.stdout.write('Bye World')

pre_command.connect(handle_pre, command='runserver')

post_command.connect(handle_post, command='runserver')

I believe this also can be used by Django itself as there are some cases where contrib apps override core command functionality (I believe this happens for staticfiles app overriding runserver)

Should I create a ticket about it?

--
Best wishes,
Dmitry Gladkov

On 16 January 2017 at 14:47, Adam Johnson <m...@adamj.eu> wrote:

Hi Mathieu,

We implemented something similar at YPlan but discovered that it wasn't a good idea as a system check, because if a dependency changes from another devs work then often Django can't even start and run the system check. Especially a problem when upgrading Django itself! Instead we implemented it as a function that runs in manage.py before Django is even loaded.

We open sourced our work as https://github.com/YPlan/pip-lock . Check it out.

On Mon, 16 Jan 2017 at 04:18, mathieu.tortuyaux <mathieu....@gmail.com> wrote:

Hello everyone, 

I would propose this new Django feature. Now you can check if your dependencies are up-to-date (e.g with `hypothesis` in attachment picture) (it runs with Python2.7 && Python3.6).

It is a good habit to check if dependencies are up-to-date, especially for security reasons. 

I did not find any references about this in Django issues

So I wondering if I can have any feedback on this ?

Thank you for taking time to read these words. 

Mathieu Tortuyaux

--


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+unsubscribe@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/5a6fb42e-e5c8-4608-9b20-19fc829473b1%40googlegroups.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+unsubscribe@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/CAMyDDM1CeOVQoH8jN35OwxOJUbhVr99gMtchgFsxbPZXac2tcw%40mail.gmail.com.

[Adam Johnson]

I believe this also can be used by Django itself as there are some cases where contrib apps override core command functionality (I believe this happens for staticfiles app overriding runserver)

The signals as proposed can't really be used for the staticfiles override, since that requires subclassing and wrapping a function to change the handler ( source ). If there are other use cases I think they'd also normally be better handled by more specific signals, e.g. post_migrate, rather than a generic all-commands signal.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BkbqrUn%2BRnpfuO48WSo%2B8rrtxy%3D%2BUyQK%2Btn14ADbN2m5NcGtQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[James Bennett]

On Mon, Jan 16, 2017 at 4:47 AM, Adam Johnson <m...@adamj.eu> wrote:

We implemented something similar at YPlan but discovered that it wasn't a good idea as a system check, because if a dependency changes from another devs work then often Django can't even start and run the system check. Especially a problem when upgrading Django itself! Instead we implemented it as a function that runs in manage.py before Django is even loaded.

On top of this, a cleaner solution is to use a monitoring service (like https://requires.io/) to keep track of dependencies and get notified of issues (especially useful since those services can break down issues like "this is out of date" versus "this has known security issues").

[Adam Johnson]

Woops I misunderstood the original idea. YPlan's pip-lock isn't for checking if the packages are the latest versions as on PyPI, it just checks the current virtualenv is in sync with the requirements.txt file(s) that define it - e.g. if a developer adds a new dependency, the rest of the team need to install it. For us this boils down to a vagrant provision, so that's what the message says.

I agree, requires.io is a nice service for this.

--

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+unsubscribe@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/CAL13Cg9cqjBa_kyncL-jjOCk57iLbHyV6e7AefyQTwccQhyQSA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Dmitry Gladkov]

On 16 January 2017 at 15:36, Adam Johnson <m...@adamj.eu> wrote:

The signals as proposed can't really be used for the staticfiles override, since that requires subclassing and wrapping a function to change the handler ( source ). If there are other use cases I think they'd also normally be better handled by more specific signals, e.g. post_migrate, rather than a generic all-commands signal.

I agree that staticfiles override is a bad example as signals should not be used to alter it's sender's behavior, however generalizing pre_migrate/post_migrate into command signals doesn't seem like a bad idea to me. Anyway, I created a PR with PoC implementation of command signals with slightly different usage that my previous example code: https://github.com/django/django/pull/7857