Should we add a dependency on the multipledispatch library, or vendor it?

[Josh Smeaton]

This has been briefly discussed before, but we need to form a consensus on whether we vendor or depend on the multipledispatch library for the following PR: https://github.com/django/django/pull/6395

The brief overview of the patch is to allow operators on different expressions to generate different SQL. An example:

.annotate(combined=F('cost') + F('tax')) -> SELECT .. cost + tax as combined ..

.annotate(combined=F('first_name') + F('last_name')) -> SELECT .. CONCAT(first_name, last_name) ..

As you can see, the operators are the same (+) but most (all?) SQL dialects don't allow you to use the + symbol for concatenation.

As for whether or not to add the dependency we can look to https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst for guidance. I'll copy the guidelines below:

• Stable - there aren't many releases. Seems to keep up to date with Python releases but not much else.
  
• Maintained - last release was 3 months ago, but see point above.
  
• Takes security seriously - N/A to date
  
• Works on all the same platforms as Django does - Yes
  
• Backwards compatible in minor releases. - Yes
  
• Confident that point-releases of won't break Django. - Yes.
  

I believe multipledispatch meets all the criteria for being an acceptable dependency. I don't see much value in vendoring the library if we're going to need to remember to keep it up to date with Django releases. The precedent was set with pytz recently.

Does anyone have a problem with declaring multipledispatch as a dependency?

Thanks

[Aymeric Augustin]

Hello Josh,

I prefer adding this library as a dependency to vendoring it.

Best regards,

-- 

Aymeric.

--
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/d46cfb10-1698-4534-8a0f-ec5d75b5226d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florian Apolloner]

Jupp, dependency is fine imo.

[Tim Graham]

The main question for me is what version specifier (if any) to use in Django's setup.py. One didn't seem appropriate for pytz since the latest version should always be fine and it doesn't follow semantic versioning anyway. I see multidispatch is now at version 0.4.9 but it's not clear to me in what version it might introduce some potentially braking changes (1.0? 0.5?).

[Aymeric Augustin]

Hello,

I think it would be best for Django to depend on the current version, that is, no version specifier. If something breaks, we can update Django and add a minimum version specifier.

I dislike maximum version specifiers because they tend to get forgotten until something else depends on an incompatible minimum version number. Then users who want both libs hit a wall.

To avoid unexpected upgrades, projects should pin their dependencies recursively, typically with pip-tools, and test when updating dependencies. This is a project-level concern. Django shouldn’t add constraints.

I hope this helps,

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a9e5a106-8733-4b62-bb7c-9b70accfe478%40googlegroups.com.

[Adam Johnson]

I agree, it doesn't seem likely there will be breaking changes in it either.

According to DEP007 ( https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst ), dependencies should go through on the feature DEP rather than just via the mailing list.

And btw was https://pypi.python.org/pypi/overloading considered? That's the syntax that the deferred PEP 3124 ( http://legacy.python.org/dev/peps/pep-3124/ ) suggested, implemented as a third party library. Python 3 only but Django 2.0 is now very close...

-- 

Aymeric.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsub...@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/a9e5a106-8733-4b62-bb7c-9b70accfe478%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/54B8A83D-C819-45B6-B98F-E3B861C395F5%40polytechnique.org.

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

--

Adam

[Tim Graham]

Maybe the dependencies DEP (currently at draft status) needs a revision to allow for dependencies without requiring a feature DEP. I interpret the current wording to imply that dependencies are only added as part of major features, however, I don't think the current feature for multidispatch nor the pytz requirement would require a DEP otherwise.

-- 

Aymeric.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a9e5a106-8733-4b62-bb7c-9b70accfe478%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-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/54B8A83D-C819-45B6-B98F-E3B861C395F5%40polytechnique.org.

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

--

Adam

[Josh Smeaton]

I agree with Tim. I think the intent is to add dependencies as part of a feature, not specifically as part of another DEP (which I don't believe this feature needs). I don't think `overloading` was considered as a dependency, but it's interesting. If this feature doesn't make 1.11 (it potentially could if it's cleaned up) then perhaps we could take a better look at overloading for 2.0.

[Josh Smeaton]

It seems everyone that has chimed in prefers adding a dependency to vendoring. If there are alternative views please express them, but I'm going to recommend a dependency on the PR.

Thanks