Re: 1.8 shipping invalid .py files in the startapp template

Hello, I'm another Debian developer co-maintaining Django in Debian. Le lundi 30 novembre 2015, Florian Apolloner a écrit : > I am not against including it, but depending on how packaging works in > Debian it could be possible to call pycompile with a proper exclusion list > instead. The PR its

Problem migrating from South to Django migrations for Linux distributions

[ Please keep me in CC ] Hello, I'm one of the python-django Debian package maintainers and I have been working on preparing the field for Django 1.7... and we have one problem that we don't know how to handle. Consider that Debian contains Django but also Django applications using South. When o

Re: Problem migrating from South to Django migrations for Linux distributions

Hi Andrew, thanks for your quick answer. On Thu, 24 Jul 2014, Andrew Godwin wrote: > There is no way around this; it's unfortunate that the packaging situation > means that Django will get auto-upgraded as part of a distribution upgrade; > I'm surprised that Debian hasn't had this with packages

Re: Problem migrating from South to Django migrations for Linux distributions

Hi Brian, On Fri, 25 Jul 2014, Brian May wrote: > I can't help but think this might be unrealistic (?). Changes required for > new versions of Django often break compatibility with old versions, and > 1.4.5 is really old now. Just because many packages don't have versioned > dependencies on Django

Sqlite 3.12 breaks the Django test suite

[ CCing an upstream developer of SQlite too ] Hello, I did not want to open a ticket as I'm not sure if the problem is in SQLite or in Django but the Django test suite fails really badly with SQLite 3.12.0 that got recently released (and which is already in Debian Unstable). When using the defau

Re: Sqlite 3.12 breaks the Django test suite

Le jeudi 07 avril 2016, Aymeric Augustin a écrit : > This other ticket about a SQLite segfault may or may not be related: > https://code.djangoproject.com/ticket/24080 Given how old it is, I was tempted to say it's entirely unrelated. But maybe not. I discovered faulthandler thanks to this and the

Adding a database-agnostic JSONField into Django

Hello, in almost all projects I work on, I end up using a JSONField. Since I value being able to run with any database, I'm not relying on django.contrib.postgres.fields.JSONField. So I have been using pypi's django-jsonfield maintained by Matthew Schinckel: https://bitbucket.org/schinckel/django-

Re: Adding a database-agnostic JSONField into Django

Hi, Le jeudi 23 juin 2016, Aymeric Augustin a écrit : > On 23 Jun 2016, at 15:40, Tim Graham wrote: > > Marc said, "I'm happy for JSONField to be made a core field on the > > condition that it's underlying support is more than a text blob on all > > our main databases. It sounds like this will so

Re: Adding a database-agnostic JSONField into Django

Le vendredi 24 juin 2016, Aymeric Augustin a écrit : > On 24 Jun 2016, at 09:01, Raphael Hertzog wrote: > > Why would you want to discourage people? > Well, this seemed to be the latest decision, but I don’t care much myself. AFAIK only Marc Tamlyn insisted on such a requirement to

Re: Adding a database-agnostic JSONField into Django

Hi, Le vendredi 24 juin 2016, Shai Berger a écrit : > > Why would you want to discourage people? In the recent thread "Extending > > JSONField serialization", you said yourself that the use-case for a > > JSONField is clearly to store and retrieve data and not to make queries on > > it with smart

Re: change commit message format to present tense?

Hi, Le lundi 27 juin 2016, Reinout van Rees a écrit : > > (You must) "add password validation to prevent the usage of..."! > > "It might be better to think of it as...": it is exactly this extra > thinkwork that everyone reading the messages has to do. We write it once and > read it many times: w

Guidelines to name python modules of Django applications?

Hello, in Debian we recently had a discussion about the package name we use for Django applications/extensions, it's usually python-django-. But the generic naming policy we have for all Python modules implies that this package would provide a "django_foo" Python module and this is not always the

Re: Guidelines to name python modules of Django applications?

Le mercredi 07 décembre 2016, Aymeric Augustin a écrit : > In my experience: > > - many Django-related packages use a django- prefix in the name of the package > on PyPI And the mismatch between package name and module name means that we have many packages which are not co-installable because t

Re: Guidelines to name python modules of Django applications?

Le jeudi 08 décembre 2016, Raphaël Barrois a écrit : > If I understand correctly the input, would the following proposal be an > acceptable middle ground? It would certainly be an improvement from my point of view, yes. Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover