Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
Thomas Goirand writes: > Feel free to raise this on a Django upstream message. I very much agree > this isn't best. I believe there is (or at least was, and probably still is) general agreement that the Django settings mechanism is horrible for numerous reasons. IIRC this has been discussed at past PyCON AU conferences. Unfortunately, this has been labelled as a "hard problem". As in coming up with a replacement that the Django core developers can agree to is non-trivial (which also means dealing with existing applications in a sensible manner). e.g. do a google search for "django settings class" and you will see that there are a number of projects to get class based settings for Django. A feature I really wish Django supported out of the box. Unfortunately most of these projects (I might have missed something) appear to have been abandoned. Maybe this is an isssue that needs to be pushed at PyCon or PyConAU. If there isn't an existing upstream bug report already, somebody should definitely file one. Or add details as to how the problem affects testing, if not already given. I don't believe the bug report by itself will solve this problem, but I think it is a necessarily prerequisite for a solution. -- Brian May
Re: Testing Django Packages, was: Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
On 04/21/2018 11:10 PM, Scott Kitterman wrote: > I believe we could benefit from more documentation and perhaps tools to make > it easier to integrate tests for Django modules. > > Scott K I agree, and it would be nice to have it within within the python-django-common package, so one could use it for tests. Cheers, Thomas Goirand (zigo)
Testing Django Packages, was: Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
On April 21, 2018 8:56:52 PM UTC, Thomas Goirand wrote: >On 04/21/2018 08:23 AM, Helmut Grohne wrote: ... >> After the dust has settled, I can follow up on d-devel with a summary >> that suggests filtering this particular django exception. > >Again, instead you could setup a working Django environment and restart >the tests. I'm not sure how hard that would be though. I maintain several Django packages that have upstream tests. When I looked into running the test suite either during package build or as an autopackagetest, I concluded it was more trouble than I had patience for. I believe we could benefit from more documentation and perhaps tools to make it easier to integrate tests for Django modules. Scott K
Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
On 04/21/2018 08:23 AM, Helmut Grohne wrote: > Control: severity 896234 normal > Control: severity 896242 normal > Control: severity 896272 normal > Control: severity 896306 normal > Control: severity 896307 normal > Control: severity 896328 normal > Control: severity 896378 normal > Control: severity 896396 normal > Control: severity 896429 normal > > I have lowered the severity of the relevant bugs (matching > "ImproperlyConfigured") to prevent issues with testing migration. Instead, please *CLOSE* those bugs unless you've done proper testing. > I wonder whether we can draw anything useful from these bugs before > closing them. Unless you try to setup a working Django env before doing the import, I'm afraid you can't draw anything. > So yeah, for django this may make sense, but this behaviour is still > unfortunate from a qa pov. Feel free to raise this on a Django upstream message. I very much agree this isn't best. > After the dust has settled, I can follow up on d-devel with a summary > that suggests filtering this particular django exception. Again, instead you could setup a working Django environment and restart the tests. I'm not sure how hard that would be though. Cheers, Thomas Goirand (zigo)
Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
Control: severity 896234 normal Control: severity 896242 normal Control: severity 896272 normal Control: severity 896306 normal Control: severity 896307 normal Control: severity 896328 normal Control: severity 896378 normal Control: severity 896396 normal Control: severity 896429 normal On Sat, Apr 21, 2018 at 09:47:59AM +1000, Brian May wrote: > Helmut Grohne writes: > > > django.core.exceptions.ImproperlyConfigured: Requested setting > > DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must > > either define the environment variable DJANGO_SETTINGS_MODULE or call > > settings.configure() before accessing settings. > > I believe this bug report, and several others you filled recently that > contain this same text are false. I went passed the bug list to a few others for review and posted the full list to d-devel (including all tracebacks). Nobody spoke up and Chris Lamb vaguely said that the django ones looked legit to him. I have lowered the severity of the relevant bugs (matching "ImproperlyConfigured") to prevent issues with testing migration. > Like it or not, it is just not possible to import Django libraries > without providing a valid django settings file. This is not a sign that > something is broken. I wonder whether we can draw anything useful from these bugs before closing them. For one thing, you cannot use autopkgtest-pkg-python on these modules as is. Then having them not importable means that e.g, pydoc. That's unfortunate. Often times, modules with non-trivial impact on their environment do not do so at import time, but provide something like an install function such that the user makes a conscious choice. An example would be gbulb.install(). So yeah, for django this may make sense, but this behaviour is still unfortunate from a qa pov. I'd like to hear your opinion on this matter. After the dust has settled, I can follow up on d-devel with a summary that suggests filtering this particular django exception. Helmut
Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
Helmut Grohne writes: > django.core.exceptions.ImproperlyConfigured: Requested setting > DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must > either define the environment variable DJANGO_SETTINGS_MODULE or call > settings.configure() before accessing settings. I believe this bug report, and several others you filled recently that contain this same text are false. Like it or not, it is just not possible to import Django libraries without providing a valid django settings file. This is not a sign that something is broken. -- Brian May