i dont remember this from 1.3 and i cant find it in the docs.
startproject appears to create both a project and an app underneath it. they've both got the same name.
python ./bin/django-admin.py startproject webapp
creates
/webapp/manage.py
and
/webapp/webapp/settings.py and others
anyone know why or link me to the page of the docco that explains this new behaviour? just skim read through the release notes and can't find anything.
I assume you are trying out 1.4b1.
This is infact the new project layout. It is mentioned in the release notes and they can explain it better than I can :).
https://docs.djangoproject.com/en/dev/releases/1.4-beta-1/#updated-default-project-layout-and-manage-py
It's not actually an app but more about tidying of default files. As such it is not in INSTALLED_APPS and will not be processed in the same way as an app. This is a trap I fell into when my custom templatetags weren't being picked up.
It's not creating an app. The directory inside is your project. The outside container is just a wrapper. manage.py has been move outside the scope of the project. See: https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py
Related
I am trying to change the admin HTML templates but I don't really now how to find the already created Django templates in the first place.
Is there an easy way to find all the templates?
Right now I am making new html templates and extending them to Djangos templates.
If you just look for an easy way to change the admin template you can use the django-admin-interface. You can change colors and it looks a bit more attractive. This works in my case pretty good.
pip install django-admin-interface
Is there an easy way to find all the templates?
Yes, they're all in the django/contrib/admin/templates/admin. You should be able to find the top-level django directory in the site-packages directory where you installed your Python packages. For example, if you created a .venv directory, it could be in .venv/lib/python3.8/site-packages/.
Otherwise, you could find the templates in the Github repository here.
The Django guide recommends copying those templates over to your own templates directory.
I develop a site with Django and PyCharm.
I just linked my project to a GitHub repository, pushed the git-ignore file to make a test, and then I closed the project, when I reopened the project, Pycharm started to make some initialization, and all my Django project has been destroyed... I tried to find some files with recuva, the only thing I founded was a xml file.
When I open the project, the github repository is not even linked anymore.
And in the right upper corner I can see one of my old html file : base.html. (see the capture).
I don't know what to do, please tell me we can do something.
This is multiple days of works who have vanished.
I resolved the problem. The Project was in the the recycle bin, I can assure you that it's the first think I have looked, and it wasn't there at the first time, and I can't explain why it was put there by the IDE.
What a panic !
In every youtube tutorial I'v seen people simply add "app_name" to INSTALLED_APPS list.
Yesterday I started Official Django Tutorial and they suggest "app_name.apps.App_nameConf" notations.
Im guessing official way is a better way and it's not hard to memorize additional syntax, I just wanna be sure. Because stuff works ether way.
Please give me a simple, easy to understand answer so even I could get it. Thanks!
You are right, following official way is a proper way, since the created video tutorials or third party blogs may refer to the older version of the django and such way is deprecated now.
Good luck in your beginnings!
In INSTALLED_APPS one can specify all apps used in this django project app.
However, you can create multiple apps in one project. By default this would result in separate directories name in root project directory.
As all apps are in root project directory - this allows to specify only (their) directory name in INSTALLED_APPS.
On the other hand, we can specify full path to project sub-app AppConfig, not relying on auto-discovering / that sub-app is located in root project directory etc.
Multiple apps in one project?
Yes, multiple apps of one project are usually tightly coupled to this specific project and cannot be used outside of it.
The main idea is separation of concerns - to split the logic into separate sections, each responsible for some part of project app.
When your app starts growing, more different logic is being added to it, models.py / views.py / forms.py etc starts growing, making it difficult to read and understand project structure as a whole.
Even in small project - separating into sub-apps may be very helpful in terms of organizing things.
There are different styles of how to organize your django app, like where should sub-apps directories be located (i.e. in root directory, or in sub-directory with project name), and apps and settings directories can be located not in root project directory. In such cases being able to specify path directly to AppConfig class is nice and also more explicit, which is better than implicit.
default_app_config is mostly used in reusable apps - apps intended to be distributed and used by other people - published to pypi. This allows just add their name in INSTALLED_APPS, not full path to their AppConfig.
You should not use it in your project unless you know that you need it.
The polls.apps.PollsConfig is the newer, more explicit way, and it better allows multiple configurations of the same app.
The reason why polls works is that polls/__init__.py likely has a
default_app_config = 'polls.apps.PollsConfig'
line.
You have to activate your model, and Django needs to know that you have your app installed.
So in settings.py you need to add 'polls.apps.PollsConfig' in INSTALLED_APPS topic because in your app.py file you have likely defined a class PollsConfig:
In settings.py
INSTALLED_APPS = [
'polls.apps.PollsConfig,
'django.contrib.admin',
'<other app...>',
]
In apps.py
class PollsConfig(AppConfig)
name = 'polls'
Im looking for a reasonably simple toolset and workflow for incorporating Sass into my Django projects. Im predominantly backend focused and have just started investigating Sass, so bear with me.
My initial idea was to keep things simple by just using node-sass without trying to incorporate Gulp, django-pipeline or anything else initially.
My Django apps are usually structured such that I create a static/app/css folder in each app. One option I guess would be to now create an additional folder per app for scss files, ie: static/app/scss. The problem there would be that when running collectstatic in production, the scss files will be gathered as well. So should the scss files for each app be kept somewhere else? (I guess it doesn't really matter if the scss files are included when collectstatic runs?)
Next, outside of my Django project folders I would create a folder to install node-sass since I wouldn't want to install it globally and I don't want the node-modules folder inside my Django project or inside source control.
I guess the node-modules folder can be thought of like using a python virtualenv instead of installing packages globally?
Next, inside my Django project somewhere (not sure where?) I would have the package.json file containing a scripts section for every scss file I want compiled to css, eg:
"scripts": {
"compile:sass": "node-sass app1/static/app1/scss/style.scss app1/static/app1/css/style.css",
"compile:sass": "node-sass app2/static/app2/scss/style.scss app2/static/app2/css/style.css",
"compile:sass": "node-sass app3/static/app3/scss/style.scss app3/static/app3/css/style.css"
}
Lastly, I would just run compile:sass with the watch flag to constantly compile any files I work on and put them in the correct folders.
So my questions are, is the above setup a good approach (at least initially if im not ready to add yet another tool like Gulp etc to the mix)?
Also, how will I run compile:sass considering my package.json file will be in the Django project somewhere and the node-modules folder containing the node-sass installation will be somewhere else.
I help maintain node-sass, so I won't say not to use it. There is an alternate libsass-python that you might want to look at if you're working with Python though.
Check out the django-sass-processor package. It's simple to configure and use. I've used it a few times and have had good experiences with it. The package abstracts away Gulp, so you don't have to worry about it and streamlines the whole process.
Here's a tutorial on how to integrate django-sass-processor into a Django project.
I am trying to reuse an existing django app, django-reviews. I set it up based on the instructions and the code is now under dist-packages.
>>> import review
>>> review
<module 'review' from '/usr/local/lib/python2.7/dist-packages/review/__init__.pyc'>
The other apps that I am writing are under my project's root directory, which is under version control along with requirements.txt
Problem
Some of the conventions are different between the app's code and my code. For instance,
1) the templates in the app extend {% base.html %} and my base.html is actually named {% "__base.html" %"}.
2) The url structure for signing in for the app is accounts/sign_in, but my current sign_in url is at "/log_in"
Question
Changing the code under dist-packages doesn't seem like a good solution, as it will be outside of my version control and it isn't in my project's home directory either. Changing my code to match the app's logic will be a problem if there is any other conflicting app in the future.
Should I instead use the source code as a reference and create a new app called review in my project's home directory?
What is the recommended approach when dealing with such issues?
Modifying code in the dist-packages directory is never a good idea. I only do it to debug packages I use, but never for a permanent change.
If you do need to change the source code of a package, you best fork the repository and make your changes. You can add it to your project the way you want it (as Git submodules, or just import it in your existing repository).
However, the idea of a django reusable app is that it's reusable for many purposes and you don't have to fork it to make it usuable for you. Maybe this app isn't configurable enough for you. You can try to contribute to this project to make it more configurable, so it's more accessible to more people. That's of course a little bit more work, but can be fun!