To make a long story short: when I install django it comes with migrations that I deleted in the past.
Here is what I do:
$ mkvirtualenv foo
$ (foo) pip install django
Collecting django
Using cached Django-1.11.5-py2.py3-none-any.whl
Collecting pytz (from django)
Using cached pytz-2017.2-py2.py3-none-any.whl
Installing collected packages: pytz, django
Successfully installed django-1.11.5 pytz-2017.2
Now when I look in the directory where the venv is created I can see migrations in the default django apps (admin, user, ect.) I also see migrations in a brand new project.
This problems started after I tried to reset my migrations. I deleted the migrations from each app and dropped all the tables. Then I removed the migrations in the venv, while doing this I accidentally removed a django app. The missing app forced me to uninstall and install django.
Even when I tell pip not to use the cache --no-cache-dir, I still get the migrations.
This is by design. The default apps that come with Django need the tables created by those migrations.
If you don't need those apps, remove them from INSTALLED_APPS in settings.py.
Related
I have a problem with migrations on heroku.
I have just upgraded version of django from 1.8.1 to 1.8.2 in my project on heroku, because of some missing migrations:
https://github.com/django/django/blob/1.8/django/contrib/auth/migrations/0005_alter_user_last_login_null.py#L14-L18
After this upgrade, on my local project I was forced to do standard procedure:
python manage.py makemigrations
python manage.py migrate
Of course this new, generated migrations are outside of my git repository. If I will run heroku run this will generate new migrations in new dyno, so without any impact on my current slug.
What is the best solution for this situation? How to generate migrations or add missing migrations of django or 3rd part libs when e.g. you are doing upgrade of the libs? What is the best working strategy?
Answer is quiet trivial, could be useful for others.
To use MIGRATION_MODULES is the correct answer.
https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-MIGRATION_MODULES
I'm using Django==1.6.5 and djangorestframework==3.0.3 with South==0.8.4. And I am using virtualenv.
In settings INSTALLED_APPS I have both rest_framework.authtoken and rest_framework. Isn't the rest_framework.authtoken redundant?
When I run migrations it creates the migrations in my /Users/andi/.virtualenvs/my_virtualenv/lib/python2.7/site-packages/rest_framework/authtoken/migrations, which is of course not in my project's repo.
QUESTION:
How can I set up django rest framework to produce the migrations inside my project directory, so that, after running schemamigration locally, the only thing I have to run on server is migrate?
You are using django 1.6.5, in this version migrations were not introduced so its may give you error on running migrations because django rest framework auth token migration tries to import migrations from django.db
Upgrade your south package from 0.8.4 to 1.0.1 version that will solve your problem Please check the following link related to south version 1.0.1
http://south.readthedocs.org/en/latest/releasenotes/1.0.html
I am using south in my django project. I just added social_auth in settings.py, when i run this command:
python manage.py schemamigration social_auth --auto
It says:Nothing seems to have changed.
Please let me know how can i create tables for social auth, as by this command the table is not getting created.
django-social-auth works perfectly except that it needs South and it doesn't work with newer versions of Django.
To remove the dependencies form South in django-social-auth, simply remove the migrations created by South and create new ones using the newer migration engine from Django 1.7 >.
This is how I fixed it:
# Install django (if you haven't) and django-social-auth
(my_venv)$ pip install django django-social-auth
# Delete the South migrations
# Using a virtual environment: my_venv
# In case you use python3, replace
(my_venv)$ rm <path_to_my_venv>/lib/python2.7/site-packages/social_auth/migrations/000*
# Create an dummy django project
(my_venv)$ django-admin startproject asdf
Add django-social-auth to the asdf/settings.py file
### asdf/asdf/settings.py
...
INSTALLED_APPS = (
...
'social_auth',
)
...
Finally create the new migration for django-social-auth
# Create new migrations
$ python asdf/manage.py makemigrations social_auth
# Delete the dummy django-project
$ rm -r asdf
This fix will work for all the Django projects that work under the same virtual environment.
I don't think you need to generate migrations for social_auth, since this app should already have its migrations. Rather, you need to execute them, so after you added 'social_auth' in your settings you have to run only this command:
python manage.py migrate social_auth
I'm working with a third-party Django package, and I'm not sure how to create a schemamigration. What's the equivalent of:
./manage.py schemamigration <app_name> when I don't have a ./manage.py?
While I don't think we can create South migrations without build a real django site(btw, you also need the django site for testing). Just treat your package like other django packages, and run schemamigration <your_app_name> to create migrations for it.
You only need to let django store migrations under your package's migrations directory instead of 'env/lib/pythonXX/site-packages/' You need to install your app with pip's editable” mode.
pip install -e local_path/to/your_package
So I was installing an app in order to bootstrap my Django admin interface, and I thought this app was going to be Project specific but it appears to be installed on a global Django level.
http://riccardo.forina.me/bootstrap-your-django-admin-in-3-minutes/
https://github.com/riccardo-forina/django-admin-bootstrapped
My question is how can I uninstall it if I need to do so at a later date? I wanted my project to be as independent as possible. I was also wondering if there was a way of doing the installation within the project so that people that download my repository will automatically get it.
Also some minor questions are that after adding "add django_admin_bootstrapped into the INSTALLED_APPS list before django.contrib.admin" I was not required to run a syncdb command like we usually are when installing models. I guess this applications doesn't creates tables on my database so that is probably why, but I just wanted to know your thoughts.
I know it is a lot to answer but any clarification is appreciated. Thanks.
If you have installed the django app using pip do:
pip uninstall app_name
Or you have to go manually to your site-packages directory and remove it.
After that,
Remove the app from INSTALLED_APPS. django-admin-boostrapped might have overridden your templates. After you are done, do ./manage.py collectstatic and ./manage.py syncdb
If you're writing something that you want other people to use, and it relies on other packages (whether Django apps or more generic Python packages) it's standard to use pip. This makes it easy to install and uninstall packages, and specific versions of those packages. You can then create a requirements.txt file, which you include with your project. This lets other people know what packages are required, and they can easily install them using pip.
So, first off, install pip.
Then you would install django-admin-bootstrapped by doing:
$ pip install django-admin-bootstrapped
You can also install django using pip:
$ pip install django
If you then do this:
$ pip freeze > requirements.txt
you'll end up with a requirements.txt file that lists any packages you've installed with pip, and which version of each. Include that file with your project when you share it with others (on GitHub or wherever). Those people would then do this, to install the same packages:
$ pip install -r requirements.txt
It would also be worth installing and using virtualenv – this lets you have separate environments for your python work, so that when you pip install something it's only available in that environment. Then you can have different versions of packages (eg, different versions of Django) in each environment. Virtualenvwrapper also makes some of the common virtualenv tasks a little easier.
It's a lot to get to grips with at first, as I know from experience, but it's worth doing so and will make development easier in the long term.
As to your other question, it looks like django-admin-bootstrapped doesn't have any models, so it doesn't require any updating of the database after installation.