Backwards migration from Django 1.4 to Django 1.3 - django

Sometimes my stupid, reckless and daredevil programming gut gets me to some dangerous places:
I've started a Django 1.4 application with sqlite3 and then moved to mysql, no big deal there. But then I realized that my models fit well with a NoSql model and decided to try MongoDB with django-nonrel wich is a fork of Django 1.3 with support for non-relational databases. the version 1.4 still not ready to use yet.
So, I've branched my repo, created my virtualenv and pipinstalled django-nonrel but when I run ./manage.py shell I got this message
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/core/management/__init__.py", line 429, in execute_from_command_line
utility.execute()
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/core/management/__init__.py", line 252, in fetch_command
app_name = get_commands()[subcommand]
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/core/management/__init__.py", line 101, in get_commands
apps = settings.INSTALLED_APPS
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/utils/functional.py", line 276, in __getattr__
self._setup()
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/conf/__init__.py", line 42, in _setup
self._wrapped = Settings(settings_module)
File "/Users/marcoslhc/Documents/Proyectos/fontcase/mongoBE/lib/python2.7/site-packages/django/conf/__init__.py", line 139, in __init__
logging_config_func(self.LOGGING)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/config.py", line 776, in dictConfig
dictConfigClass(config).configure()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/config.py", line 562, in configure
'filter %r: %s' % (name, e))
ValueError: Unable to configure filter 'require_debug_false': Cannot resolve 'django.utils.log.RequireDebugFalse': No module named RequireDebugFalse
RequireDebugFalse is new in Django 1.4 (see here and here) and I guess some other underlying magic new in 1.4 would not work either in this new installation. I was wondering if I can migrate back my application to Django 1.3 without doing django-admin.py startproject or django-admin.py startapp.

You can do that, although you probably want to leave the door open to going forward again.
The way I've handled this in the past is, if at all possible, to not go making massive changes to your code. Instead, do what you've already done -- run the code and wait for it to blow up. Identify what the source of the problem is and then do one of the following:
Create a stub that supplies the needed functionality (or at least quietly does nothing),
Back-port the functionality onto your own personal copy of 1.3, or
Monkey-patch the functionality onto an unmodified 1.3. (My recommendation)
Unless you have totally glommed onto some unique new feature in 1.4, you'd be surprised how quickly you can come up with a useable environment. I had one project where the monkey-patch file was only about 100 lines long to retrofit about a dozen features onto an older version.

If you haven't used django 1.4 stuff in your project you could create a 1.3 project and copy the logging settings from there. Then you should be fine.

Related

drf-spectacular is using the wrong AutoSchema to generate Swagger

Previously I was using drf-yasg but want to update to use OpenAPI 3. I am trying to switch over to drf-spectacular. Following the instruction, I ran pip install drf-spectacular, I've removed all references to the drf-yasg package, and updated Settings.py as follows:
INSTALLED_APPS = [
...
"drf_spectacular",
]
REST_FRAMEWORK = {
"DEFAULT_SCHEMA_CLASS": "drf_spectacular.openapi.AutoSchema",
}
When I use the CLI to generate the schema, I get the bellow AssertionError. If anyone has run into this problem before and has any insight, it would be much appreciated!
I'm using Python 3.7, Django 3.0, Django Rest Framework 3.11, and DRF Spectacular 0.10.0.
Traceback (most recent call last):
File "manage.py", line 23, in <module>
main()
File "manage.py", line 19, in main
execute_from_command_line(sys.argv)
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
utility.execute()
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/django/core/management/__init__.py", line 395, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/django/core/management/base.py", line 328, in run_from_argv
self.execute(*args, **cmd_options)
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/django/core/management/base.py", line 369, in execute
output = self.handle(*args, **options)
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/drf_spectacular/management/commands/spectacular.py", line 50, in handle
schema = generator.get_schema(request=None, public=True)
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/drf_spectacular/generators.py", line 187, in get_schema
paths=self.parse(request, public),
File "/opt/anaconda3/envs/dev/lib/python3.7/site-packages/drf_spectacular/generators.py", line 160, in parse
'Incompatible AutoSchema used on View. Is DRF\'s DEFAULT_SCHEMA_CLASS '
AssertionError: Incompatible AutoSchema used on View. Is DRF's DEFAULT_SCHEMA_CLASS pointing to "drf_spectacular.openapi.AutoSchema" or any other drf-spectacular compatible AutoSchema?
Please update the Django Rest Framework 3.11 to 3.12 it will work.
I have the same issue when I had REST_FRAMEWORK two times written for different settings in my settings.py. I moved everything in one variable and error is gone
If the AssertionError is about DRF's ObtainAuthToken then it is most likely an old bug in DRF. This issue was fixed in DRF>=3.12. Prior to that, DRF used a wrong class where it was not supposed to.
drf-yasg seems to not suffer from this upstream bug due to a different injection technique used. drf-spectacular has a mitigation for the bug starting with 0.24.0.
Related GH issue with workaround for older drf-spectacular versions:
https://github.com/tfranzel/drf-spectacular/issues/796#issuecomment-1231464792
Sidenote: If this does not fix your problem and/or it is the same Assertion for some other view, you likely have a misconfigured settings.py. Make sure DEFAULT_SCHEMA_CLASS is properly set as stated in the README. Also make sure you are not shooting yourself in the foot by not setting this also in your production settings file. If the problem still persists, please open an issue on Github and get help there.
Check if you're importing from rest_framework!
Having a
from rest_framework.pagination import PageNumberPagination
was all it took to provoke the error. As soon as I removed the import, things started working again.
This even applies when importing other modules which in turn import from rest_framework. I ended up using the "sting imports" like so:
"DEFAULT_PAGINATION_CLASS": "api.pagination.DefaultPagination",

Problem with migrating a django server (syntax error)

I am trying to make a django server for a sociometric badge (https://github.com/HumanDynamics/openbadge-server) for our university's project. The code (and the whole badge) has been done by someone else and I have not myself changed anything, I am simply trying to get it to work. I am able to build the server but when trying to migrate or create a superuser, I get a syntax error. I've been trying to troubleshoot it by myself but I have very limited knowledge of python, django and Ubuntu so I'm probably missing something.
The error implies an error in the line 44 of /usr/local/lib/python2.7/site-packages/pkgconf/init.py but I cannot find the file so I cannot check it. In fact, the whole site-packages folder is empty so I wonder if I have installed modules in a wrong way? The code is written in python2.7 (Which I cannot change as it is not my code) so I also wonder if the python2.7 being EOL could cause issues? It has already broken some parts, mainly how to get some of the dependencies.
The code and docker files used in this project can be found here: https://github.com/HumanDynamics/openbadge-server
The dependency versions should be fine, the Django version should be compatible with Python2.7 and same for other modules. I've tried changing the versions around but to no avail. Down here is the requirement texts
Django==1.8.4
Fabric==1.10.2
django-grappelli==2.7.1
simplejson==3.8.0
MarkupSafe==0.23
django-pipeline==1.5.4
djangorestframework==3.2.3
djangorestframework-expiring-authtoken==0.1.1
pytz==2015.7
python-dateutil==2.5.3
jsonfield==1.0.3
django-controlcenter===0.2.6
# Configuration
django-environ==0.4.1
# Python-PostgreSQL Database Adapter
psycopg2==2.7.3.2
# Unicode slugification
awesome-slugify==1.6.5
# Import and export using the admin tool
# Using tablib 0.12.1. Newer versions break the import-export add-on
tablib==0.12.1
django-import-export==1.0.0
coverage==4.3.1
django-coverage-plugin==1.3.1
Sphinx==1.5.1
django-extensions==1.7.5
Werkzeug==0.11.15
django-test-plus==1.0.16
factory-boy==2.8.1
django-debug-toolbar==1.6
# improved REPL
ipdb==0.10.1
pytest-django==3.1.2
pytest-sugar==0.8.0
This is the error. From my limited knowledge, I'd gather that it doesn't find the files from /usr/local/lib/python2.7/site-packages/ but it is completely empty, the dependencies are either installed locally or to dist-packages. Someone earlier said that it was a python3 problem but nothing should be Python3. Could it also be a docker version problem if the build somehow installs wrong things?
Starting openbadge-server_postgres_1 ... done
Postgres is up - continuing...
Traceback (most recent call last):
File "manage.py", line 23, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 312, in execute
django.setup()
File "/usr/local/lib/python2.7/site-packages/django/__init__.py", line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/local/lib/python2.7/site-packages/django/apps/registry.py", line 85, in populate
app_config = AppConfig.create(entry)
File "/usr/local/lib/python2.7/site-packages/django/apps/config.py", line 86, in create
module = import_module(entry)
File "/usr/local/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File "/usr/local/lib/python2.7/site-packages/controlcenter/__init__.py", line 1, in <module>
from .dashboards import Dashboard # NOQA
File "/usr/local/lib/python2.7/site-packages/controlcenter/dashboards.py", line 10, in <module>
from . import app_settings
File "/usr/local/lib/python2.7/site-packages/controlcenter/app_settings.py", line 1, in <module>
from pkgconf import Conf
File "/usr/local/lib/python2.7/site-packages/pkgconf/__init__.py", line 44
class Conf(metaclass=ConfMeta):
^
SyntaxError: invalid syntax
I will provide information to best of my abilities.
Fixed the issue by adding django-pkgconf==0.3.0 to the requirements. While the requirements did not have the package at all, it was still installed (and used) through other packages and it installed version 0.4.0 which does not support Python 2.7.
Weird thing is that I could not find a trace where it was installed if I installed it without having it on requirements so even when I manually installed 0.3.0, it would still use 0.4.0 (despite seemingly not having it installed) so in order to get it to work it had to be installed through the docker build.

ImportError: No module named time

I'm trying to get a Google app up and running on my local machine, however, am facing an issue when running the setup scripts. The script errors out and tells me that there is no module time and seems to be breaking in the google-cloud-sdk....
Things I've tried:
Importing time in Python (it works)
Trying this to no avail: https://apple.stackexchange.com/questions/96308/python-installation-messed-up
Traceback (most recent call last):
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/_python_runtime.py", line 83, in <module>
_run_file(__file__, globals())
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/_python_runtime.py", line 79, in _run_file
execfile(_PATHS.script_file(script_name), globals_)
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/runtime.py", line 175, in <module>
main()
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/runtime.py", line 155, in main
sandbox.enable_sandbox(config)
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 183, in enable_sandbox
__import__('%s.threading' % dist27.__name__)
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/google/appengine/dist27/threading.py", line 13, in <module>
from time import time as _time, sleep as _sleep
File "/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 984, in load_module
raise ImportError('No module named %s' % fullname)
ImportError: No module named time
Here is my current $PATH:
/Users/kennethryan/Projects/go-edu-store/y/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Seeing as this is an inactive year old issue, we can assume that updating the Google Cloud tools to their latest versions by running 'gcloud components update' will fix this.
Also ensuring that you are using the Python installation provided by GCloud, and that there are no conflicting 'CLOUDSDK_PYTHON' environment variables should prevent this.
If this issue is seen again in the future, it is recommended to directly report this to the Google Public Issue Tracker so that this can be properly handled and triaged to the GCloud engineering team.
In my case, I resolved this problem by setting
export PYTHONPATH=$PYTHONPATH:/usr/lib64/python2.7/lib-dynload/ where timemodule.so file is located.

Django makemigrations: ValueError: Lookup failed for model referenced by field

i got this error.
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/makemigrations.py", line 125, in handle
migration_name=self.migration_name,
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/autodetector.py", line 43, in changes
changes = self._detect_changes(convert_apps, graph)
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/autodetector.py", line 110, in _detect_changes
self.old_apps = self.from_state.concrete_apps
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/state.py", line 158, in concrete_apps
self.apps = StateApps(self.real_apps, self.models, ignore_swappable=True)
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/state.py", line 236, in __init__
raise ValueError(msg.format(field=operations[0][1], model=lookup_model)) ValueError: Lookup failed for model referenced by field systech_account.User.companies: systech_account.Company
every time i try to
python manage.py makemigrations
in my (Ubuntu). but when i try to run it on my Windows and my colleagues in their(Ubuntu) it works fine. (*we share the project via Git repo). they can make the migrations successfully. we are wondering why is this happening to my PC alone.
Notes:
I'm the only one experiencing this within my team.
When i create/update model, i can't makemigrations. So, i have to push my changes to the repo for them to pull and makemigrations in their computer (WHICH THEY ARE NOT ENCOUNTERING ANY ERRORS)in their end and push the migration file to repo so i could migrate it.
"Everytime we need to make any changes to a model we need to pull from the repo first for any latest migration file then make the migration file so they will have succeeding numbers, because--"
if we don't our migration files would have so many errors because of dependencies with other migrations then we have to delete all our migration files, delete the database and do a makemigration again.(We don't know how to handle this, honestly)
Solutions we tried:
Deleted the local database
Reinstalled PSQL
Reinstalled Django
Reinstalled Python
Deleted the repo and cloned again
Deleted all the migration files(This works but why?, we don't want to delete all migrations because it will also affect our live site.)
How do we solve this?
Thanks! :)
I'm going to take a guess here that systech_account.Company is a model thats in an app that hasn't been loaded yet whilst trying to create a migration for a different app.
If this is true its probably solvable by first running
makemigrations app_that_has_company_in_it
before running your other makemigrations.
But this isn't the solution.
The fact that you and your colleagues are all trying to do the same migration tells me that you don't store the migrations in your source control which is the real problem here.
Doing this does stop these errors from ever occurring (at least for me/us) and makes it much quicker when trying to make migrations since there aren't any repeated steps. If you're worried about merge conflicts with these, you needn't worry, django is very clever.

Running django on GAE + Cloud SQL, with third party reusable django apps ( like South)

I'm planing to run a django project on google cloud plateform (GAE, Cloud SQL). The project uses several django reusable apps (libraries) like South, django-debug-toolbar, django-compressor, etc. So, i'm wondering if there is a way to manage all these libraries on appengine? if Yes, how.
PS: I've tried to define dependencies in the app.yaml file, but i'm getting errors:
Traceback (most recent call last):
File "/usr/local/bin/dev_appserver.py", line 197, in <module>
_run_file(__file__, globals())
File "/usr/local/bin/dev_appserver.py", line 193, in _run_file
execfile(script_path, globals_)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/devappserver2.py", line 855, in <module>
main()
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/devappserver2.py", line 848, in main
dev_server.start(options)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/devappserver2.py", line 657, in start
options.yaml_files)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/application_configuration.py", line 556, in __init__
module_configuration = ModuleConfiguration(yaml_path)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/application_configuration.py", line 82, in __init__
self._yaml_path)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/application_configuration.py", line 272, in _parse_configuration
return appinfo_includes.ParseAndReturnIncludePaths(f)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/appinfo_includes.py", line 63, in ParseAndReturnIncludePaths
appyaml = appinfo.LoadSingleAppInfo(appinfo_file)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/appinfo.py", line 1743, in LoadSingleAppInfo
listener.Parse(app_info)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/yaml_listener.py", line 226, in Parse
self._HandleEvents(self._GenerateEventParameters(stream, loader_class))
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/yaml_listener.py", line 177, in _HandleEvents
raise yaml_errors.EventError(e, event_object)
google.appengine.api.yaml_errors.EventError: the library "django-appconf" is not supported
in "jobbr/app.yaml", line 13, column 1
Sorry, but at least South and django-compressor would not run on GAE.
GAE is a completely different platform. Yet you have SQL access to your tables, it's just an abstraction layer over a nonrelative database. There is no filesystem access, but there are tons of other limitations. Even Django itself could not be run on GAE without patches - you have to use special version, django-nonrel.
I would suggest to read more GAE documentation so you can decide if a particular application could be run there or not.