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.
On Monday, January 2, 2017 at 1:13:13 PM UTC-5, Adam Johnson wrote: > > 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... > > On 2 January 2017 at 16:47, Aymeric Augustin < > aymeric....@polytechnique.org <javascript:>> wrote: > >> 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 <timog...@gmail.com <javascript:>> >> 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 >>>> >>>> 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 >>>> >>>> -- >>>> 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 >>>> >>>> <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. >>>> >>>> >>>> >> -- >> 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 <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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 >> >> <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. >> >> >> -- >> 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 <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/54B8A83D-C819-45B6-B98F-E3B861C395F5%40polytechnique.org?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Adam > -- 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/a1bd3769-e960-43fc-aaf1-b21c9cc98f0e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
