I am new to django and i just deployed my first django site on heroku.
Now my problem is that i have to change one line of code in a template installed through requirements.txt in pythons site-packages. Is there a way to upload that one file from my local environment to herokus environment and how could i find the folder structure of my site to upload the edited file?
I thought about making a pypi package but this seems to be too complicated for one line of code…
just run heroku run bash
cd /app/.heroku/python/lib/python2.7/site-packages
just one line but vi is not working on heroku so better follow this post and do ...
Related
After upgrading to django 1.9 and tried creating new project.Getting following error
How should i solve this?
After upgrading to django 1.9 and creating new project following error occurred
CommandError: /home/shaastr/ehgg/manage.py already exists, overlaying a project or app into an existing directory won't replace conflicting files
I think you have 2 versions of django installed, and both are being called when trying to start the project.
Try running pip uninstall django twice, if it runs both time then this was what was going on. Obviously, pip install django afterwards to get it working again
I had the same problem after using pip to install django 1.10 over an older version.
I used pip to uninstall and manually deleted the leftover django folder in the site-packages folder.
re-installed using pip, and now it is working with no problem.
I am also working with docker containers. I had this problem where it said that manage.py already exists in the workdirectory (that I made through the Dockerfile file) when I tried to restart the process of making a container after deleting the old one.
It did not show me where the workdirectory was made and hence could not delete the manage.py as pointed out in the error.
The solution that worked was I changed the service name in my yml file and gave the command with new servicenm
docker-compose run servicenm django-admin.py startproject projectnm directory
remove manage.py then re-run your django-admin startproject command, it will work
Make sure that if you have deleted (rm -r) "your Django project_name" to also delete (rm) the manage.py corresponding deleted project python file in the same repository.
sudo pip uninstall django
sudo rm /usr/local/lib/python2.7/dist-packages/django/ -rf
sudo pip install django==1.10
This resolved my problem.
You need to define another directory for your new project. Not /ehgg directory.
It seems though you are creating a new project inside your old project.
And this error clearly state that, there is old setting i.e "manage.py" for your old project. Since every time a new settings manage.py created for your new project.
I hope it's clear to you.
Thank you.
Check whether the project name is correct or not. Django avoids
hypens (-) in project names.
It can happen due to two reasons:
You are trying to create a new folder with the exiting folder name.
You have previously deleted a folder with this name. Deleted it for some reason. But again trying to create package with this name.
To resolve this follow
Rename the manage.py from your project folder.
Go to <%System Path%>/PycharmProjects/<%Your Project Name%>/.idea/workspace.xml
edit this file "workspace.xml" and then search with the package name you are trying to create.
delete that line and save the file.
Now try to run the command again.
I hope this helps.
Regards,
I'm using git to version control a Django 1.7 + Django CMS 3.0.6 project.
In the course of building various apps etc I'm ending up with a lot of migration files. The migration files are currently included in my git repo.
Thus far I have been trying to avoid including the virtual env files in my repo directly as it seems rather messy and redundant. Instead I have thus far been including a pip requirements file in the repo and using that to recreate the virtual env when needed.
However, I have recently discovered that choosing to include the migration files in the repo seems to require including all of the virtual env files in the repo as well. I say this because upon deploying my project to a production server and trying to run any of the db commands (syncdb, makemigrations or migrate) via python manage.py I get the error:
KeyError: u"Migration image_gallery.0001_initial dependencies reference nonexistent parent node (u'cms', u'0004_auto_20141108_1256')"
whereas such error does not occur on my local machine, even after deleting the database.
I tracked the source of this error down to the fact that the virtual env on my local machine has a reference to '0004_auto_20141108_1256' (inside the django-cms package - it appears some cms migration info is recorded directly inside the virtual env directory itself) while that of the production environment does not - as the production venv is create thorough a pip requirements file. Therefore, the two virtual envs do not exactly match, even though all third party libs are the same. Currently I am not including the venv in my git repo.
So as I see it I have two options:
1. include the virtual env in my git repo
2. drop the migration files from git
Which option is better and why - or is there a third even better way?
The downside to #1 is unnecessary bloat. The downside to option #2 is one loses the migration history, something one might potentially want to keep.
You never commit the virtual env, it defeats the purpose; you just add unnecessary content to git.
Instead, freeze the requirements and commit the file:
pip freeze > requirements.txt
Install the packages on the server:
pip install -r requirements.txt
The problem is in my django settings.py file:
MIGRATION_MODULES = {
'cms': 'cms.migrations_django',
'menus': 'menus.migrations_django',
'djangocms_file': 'djangocms_file.migrations_django',
...
}
I had to introduce the above to get django-cms 3.0.6 to work with django 1.7, a consequence of the fact that migrations in django 1.7 are no longer done with South, as django 1.7 now has it's own migration system, while cms 3.0.6. still expects migrations to be managed by South by default.
However, the effect of the above config is to store migrations in the above described paths which in my case pointed straight to the virtual env. Thus migration info was getting stored within the virtual env dir, leading to problems in deploying to production.
To fix this I modified my project directory structure to include a folder called "migrations":
myproject/manage.py
myproject/migrations/
myproject/myproject/
...
And modified the config to be:
MIGRATION_MODULES = {
'cms': 'migrations.cms.migrations_django',
'menus': 'migrations.menus.migrations_django',
'djangocms_file': 'migrations.djangocms_file.migrations_django',
...
}
This has the effect of now storing all migration files in the django project itself (and by extension the git repo). As migration info is no longer in the virtual env directory, there is no longer any reason to consider the rather unattractive possibility of including the virtual env in the repo.
I'm trying to work through the "Getting Started with Django" heroku tutorial. Things are working when I run the framework locally with foreman, but when I try to run it on Heroku, it is failing when trying to find the settings module.
In a nutshell, I've done...
chris#xi:~: mkdir hero
chris#xi:~: cd hero
chris#xi:~/hero: django-startproject ku .
and then I create and edit the files per the instructions. Perhaps I have gotten something wrong?
in ~/hero, I created my Procfile and requirements.txt, as well as the ku directory that was created by django-admin
in ~/hero/ku I have settings.py and wsgi.py (created by django-admin and edited by me)
any idea what I'm not doing correctly?
found it after much trial end error. It turns out that I had an old .gitignore file in my home directory that ignored settings.py. Once I added settings.py to the project and re-pushed, everything started working.
I don't like putting settings.py into git because it contains machine-specific information, as well as security information. But I guess I will leave it for now, and when I have to do it for real, I can use the heroku config:set command to set up things like database users and passwords, or paths to DJANGO_SETTINGS_FILE, etc.
I am having trouble getting a simple GeoDjango app running on heroku. I have created the postgis extension for my database but I am not able to run syncdb without getting the following error:
from django.contrib.gis.geometry.backend import Geometry
File "/app/.heroku/python/lib/python2.7/site-packages/django/contrib/gis/geometry/backend/__init__.py", line 14, in <module>
'"%s".' % geom_backend)
django.core.exceptions.ImproperlyConfigured: Could not import user-defined GEOMETRY_BACKEND "geos".
Any ideas what I am doing wrong? Also does anyone know of a tutorial for getting a simple geodjango project running on heroku? Thanks for your help
I ran into this same issue and Joe is correct, you are missing a buildpack. What I did differently was include both the heroku-geo-buildpack and the heroku-buildpack-python. Both can be included by using the heroku-buildpack-multi and adding a ".buildpacks" file to your home directory in which to include the other buildpacks.
https://github.com/ddollar/heroku-buildpack-multi
So set buildpack-multi as your buildpack and add a .buildpacks file in your project base directory:
$ heroku config:set BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git
$ touch .buildpacks
# .buildpacks
https://github.com/cyberdelia/heroku-geo-buildpack.git#1.0
https://github.com/heroku/heroku-buildpack-python
When you push this, Heroku will install the software packages required to run python (python, pip, etc), along with the software packages required to run postgis (geos, proj and gdal).
I gave heroku-buildpack-geodjango a try but I believe it might be out of date (hasn't been updated in a year).
I just ran into the exact same error after using the multi buildpack method from ddollar https://github.com/ddollar/heroku-buildpack-multi with no problems up until this morning. As Jeff writes, you just point your buildpack at the multi and then add a .buildpacks file.
$ heroku config:set BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git
$ cat .buildpacks
# .buildpacks
https://github.com/cyberdelia/heroku-geo-buildpack.git
https://github.com/heroku/heroku-buildpack-python
Also dont forget to add django.contrib.gis to the apps in settings.
Everything should go well and install the geos and gdal libs when you push to heroku but you will find that django doesnt find them and you get the error. This is because django wants the full path as per the docs:
https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/geolibs/
So add this to settings.py:
GEOS_LIBRARY_PATH = "{}/libgeos_c.so".format(environ.get('GEOS_LIBRARY_PATH'))
GDAL_LIBRARY_PATH = "{}/libgdal.so".format(environ.get('GDAL_LIBRARY_PATH'))
It seems like you are missing some C libraries. Consider the GeoDjango Heroku buildpack:
https://github.com/cirlabs/heroku-buildpack-geodjango/
heroku create --stack cedar --buildpack http://github.com/cirlabs/heroku-buildpack-geodjango/
git push heroku master
The required libraries should be installed automatically using these commands.
I would like to deploy two separate Django applications to Heroku. Two applications, with two separate domain names, that are logically different from each other. I set up a venv that contain all the Python/Django stuff. Now, I could create another application that duplicates all the Python/Django stuff in another project. But, is there a way to use the same venv?
My file structure currently looks like this
django
-.git
-projectname_1
-venv
.gitignore
requirements.txt
When I tried to add projectname_2 under django I got an error saying Django app must be in a package subdirectory
Is there a correct way to add a second application using the same venv?
This error occurs when your project doesn't conform to Heroku's specs for a Django project.
Specifically, that particular error occurs when Heroku did not find a settings file at ~/your_app_name/settings.py and therefore assumed it's a non-Django Python app. But then it did find settings.py and manage.py at your project root (~/).
The specific Heroku source code that throws this error is:
https://github.com/heroku/heroku-buildpack-python/blob/master/bin/compile
Your directory should look something like this:
~/.gitignore
~/Procfile
~/requirements.txt
~/your_app_name/
~/your_app_name/manage.py
~/your_app_name/settings.py
~/your_app_name/etc...
Your best bet really is to use two separate Heroku apps. Heroku makes some assumptions about what type of app you are deploying and doesn't necessarily account for multiple apps.
Also, it's probably best to not check in your virtualenv. Just make sure all your dependencies are defined in requirements.txt and Heroku will install them automatically inside a new virtualenv.