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. > On 2 Jan 2017, at 17:23, Tim Graham <timogra...@gmail.com> wrote: > > 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?). > > On Monday, January 2, 2017 at 8:07:52 AM UTC-5, Florian Apolloner wrote: > Jupp, dependency is fine imo. > > On Sunday, January 1, 2017 at 7:13:24 PM UTC+1, Aymeric Augustin wrote: > Hello Josh, > > I prefer adding this library as a dependency to vendoring it. > > Best regards, > > -- > Aymeric. > >> On 1 Jan 2017, at 06:36, Josh Smeaton <josh.s...@gmail.com <>> wrote: >> >> This has been briefly discussed before, but we need to form a consensus on >> whether we vendor or depend on the multipledispatch >> <https://github.com/mrocklin/multipledispatch> library for the following PR: >> https://github.com/django/django/pull/6395 >> <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 >> <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 >> >> -- >> 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 >> <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 >> >> <https://groups.google.com/d/msgid/django-developers/d46cfb10-1698-4534-8a0f-ec5d75b5226d%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <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+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <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 > > <https://groups.google.com/d/msgid/django-developers/a9e5a106-8733-4b62-bb7c-9b70accfe478%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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+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/54B8A83D-C819-45B6-B98F-E3B861C395F5%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
