Hi,
Sorry I missed this thread!
Adam is (or is planning..) writing a DB backend that includes MySQL and
> MariaDB
>
Not technically, I'm actually writing a backend to use the newer MySQL
DBAPI library pymysql at
https://github.com/adamchainz/django-pymysql-backend . For the first pass
at lea
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
potential
Hi,
this is a question on how to interpret the asgi specs of django channels:
https://channels.readthedocs.io/en/latest/asgi.html
If this is the wrong place to discuss it, then please point me to the
right place.
I used some free time to learn the language "go" and tried to write a
protocol ser
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
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.pytho
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
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
Now that Python 2 is dropped in Django 2.0 and a faster implementation of
pbkdf2 is guaranteed to be available (from what I understand), it's time to
reevaluate our strategy for increasing the number of iterations each
release.
I'm not sure how to evaluate potential performance issues from bump
I think this has cleaned up to request input (I'm a bit zealous to make
something that will be merged). I left a note in 1.11.txt but when 2.0.txt
is introduced, I'll move it there. Also, now everything is in places that
are not PostgreSQL-only. I realized in the process that the only thing
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 >
> wrote:
>
> This has been brief
10 matches
Mail list logo
