Pycharm not showing all files from django external library - django

In pycharm under external libraries I'm not able to see all files (e.g all templates are missing).
The external librarys are coming from a remote server (docker).
On the server itself, I'm able to see every file.
Pycharm
Docker container
root#fcb645e62162:/usr/local/lib/python3.5/site-packages# ls django/contrib/admin
__init__.py actions.py checks.py exceptions.py forms.py locale models.py sites.py templates tests.py views
__pycache__ apps.py decorators.py filters.py helpers.py migrations options.py static templatetags utils.py widgets.py

This should work in the latest PyCharm build, but maybe there's something
special in your case that breaks it.
Try update version.
or go to Settings | Project Structure and add the folder with
your Django installation as a content root to your project.

Related

PyCharm cannot resolve reference in __init__.py with Django project apps

I am at my wits end with this issue, and would love some help resolving this.
I have a Django project with a bunch of sub apps as such:
my_project/
manage.py
my_project/
settings.py
urls.py
wsgi.py
app_root/
__init__.py
app1/
__init__.py
models.py
views.py
urls.py
templates/
[various templates].html
app2/
__init__.py
models.py
[etc]
app3/
[etc]
in my django settings.py i have installed apps as such:
app_root.app1,
app_root.app2,
In PyCharm, I've tried various things but essentially have Content Root as the top "my_project/" and app_root, app1, app2, etc as Source Roots. I've tried just having app_root as the only Source Root, and I've tried having only app1, app2, etc only as Source Roots, but nothing makes any difference.
Everything functions fine. app runs and everything. However, PyCharm has an inability to resolve my apps.
However, if i try this:
import app_root
...
def some_function(self):
app_root.app1.models.My_Model.objects.all()
it will highlight app1 with the error "Cannot find reference 'app1' in '__init__.py'"
This also means it can't do autocomplete anywhere in the path while doing app_root.app1. - it has no idea about models, views, etc. despite having an (empty) __init__.py in every directory.
I also cannot use any refactoring because it always says "Function is not under the source root"
I've spent countless hours trying to get PyCharm to behave but simply cannot find a way to do it. Is there any way this can be done so PyCharm will autocomplete my apps and not keep giving inspection warnings?
I had some similar issues. My solution; within the PyCharm preferences I added a path to app_root in my active Python Interpreter.
After an exchange with the PyCharm folks, here is what I learned:
Django imports all apps in INSTALLED_APPS variable and their models using __import__ for its own purposes.
In your case, it runs
__import__("app_root.app1")
__import__("app_root.app1.models")
After that, you call import app_root and obtain module app_root with app_root.app1 and app_root.app1.models already imported by internal Django code
Fact that Django imports apps and models is Django internals, it is undocumented and may be changed in future releases. We believe you should not rely on it in your production code, nor PyCharm should.
Here is example in bare python (no django):
__import__("encodings.ascii")
import encodings
print (encodings.ascii.Codec) # this code works, but PyCharm marks "ascii" as "unknown module"
So basically, it's not supposed to work as import app_root, but Django funkiness is masking that.

manage.py - not in project folder?

I'm trying out Django for the first time, and I'm trying to follow the tutorial provided by the django team.
After I've created a new project I get the following folder/file structure, just as the tutorial says I should:
mysite/
manage.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py
When I create an app I run:
python manage.py startapp polls
...which creates the app 'polls' in the same folder as the manage.py file - which gives me:
mysite/
manage.py
polls/
__init__.py
admin.py
models.py
tests.py
views.py
mysite/
__init__.py
settings.py
urls.py
wsgi.py
This means the app I created gets created outside my project folder, which, of course, should not be the case. I have tried to move manage.py inside the project folder. But when I do that and run:
python manage.py syncdb
...I get the following error:
raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e))
ImportError: Could not import settings 'testproject.settings' (Is it on sys.path?): No module named testproject.settings
I guess I could move the app manually to the project folder, but this is something I shouldn't have to do.
So, either something is wrong in the tutorial (which I have very hard to believe), or I'm missing something out here (more likely).
Thanks in advance.
This is the new proper layout. "mysite/mysite" is an app, and "mysite/polls" is an app. The "mysite" parent folder is your project folder.
#holyredbeard that is the correct layout are you reading the older documentation?
Useful reading: http://www.tdd-django-tutorial.com/blog/articles/2012/tutorials-updated-django-14-and-its-weird-new-fold/
Don't move the manage.py it should sit outside the apps and the project folder.
since 1.4 common layout example...
project_root/
project_name/
media/
static/
static_root/ (in production)
templates/some_app/foo.html (overriding some_app at project level)
/admin/some_app/some_model/change_list.html
(overriding admin changelist for some_app.models.some_model)
settings.py
settings_deployment.py
urls.py
some_app/
templates/some_app/foo.html
urls.py
views.py
models.py
manage.py
This is the official layout since version 1.4.
The rationale behind is explained well in the release notes:
https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py
Do not move manage.py. In general you can expect that Django's own scripts always do the right thing, you never need to move any files just to get it working.

project layout and project utilities/libraries?

I am a bit confused with the project layout created since Django 1.4.
I want to add some global utilities to be used through my whole project and apps.
I tried to add a utils package at the same level of my apps but Django does not see it.
mysite/
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
utils/
__init__.py
shortcuts.py
Any advice / best practice on how to use such a global utilities package ?
Thanks
Michael
Instead of adding it to PYTHONPATH which you have to do on each machine you install your project on, you can consider adding it to the django settings (mysite/settings.py) in INSTALLED_APPS variable:
INSTALLED_APPS=(myapp, utils)
This has the effect of adding utils to the python path, so you can do things like:
from utils import shortcuts

django message files work in project folder but doesn't work in app folder

I am testing django system and I started a project and a app for it. I have a problem with i18n system.
I have used _() function in app's view.py.
I put the 'django.middleware.locale.LocaleMiddleware' line in the MIDDLEWARE_CLASSES in project's settings.py file.
I run django-admin.py makemessages -l tr in app folder.
I run django-admin.py compilemessages in app folder.
When I run the service it didn't work. After I search in here and some other places I see the way how django looking these message files. First it looks app's folder, after project's folder. There are another places as well.
I moved my message files in project's folder and it worked. I moved the locale folder in app's folder again and it didn't work again.
I need to understand why. I want every translations, message files in releated app.
Regards,
I found the problem, I forgot to add the app name to INSTALLED_APPS settings. When I added, it works.
I tested it for myself and found it working.
Are you sure you use it in code in right way?
app/views.py:
from django.utils.translation import ugettext as _
from django.contrib import messages
...some code here...
if saved_changes:
messages.success(request, _('Item \'%s\' was saved.') % item.name)

Django project hierarchy/organization

I am new to Django and starting a project, and I would like to do it the right way.
I would like to know what you think is best practice for organizing a project.
Here are some questions I have:
How do I separate the static resources from the Python code so that I don't waste time processing the static content through Django?
As apps are reusable modules, they are not really tight to a project, so should they be located in the project directory, or in another directory that would contain all my "homemade" apps?
Are templates considered to be static or dynamic content?
Here is my current file hierarchy:
webapps/
myproject/
apache/
bin/
lib/
templates/
app1/
app2/
src/
app1/
app2/
__init.py
settings.py
urls.py
manage.py
myproject.wsgi
admin/
static/
css/
img/
What do you think?
What would be better?
Thanks!
Your directory structure could also depend on what version of django that you're using. If you're using django 1.3, handling static content has changed slightly. Your templates could also be arranged separately.
The following only applies for django 1.3.
Within an app directory:
...
app1/
static/
app1/
templates/
app1/
models.py
...
views.py
If you use the new django.contrib.staticfiles application, your settings may look something like this:
MEDIA_ROOT = path.join(ROOT_PATH,'uploaded_media/')
MEDIA_URL = '/uploaded_media/'
# static content is collected here, and served from here, but don't add stuff manually here! add to staticfiles_dirs
STATIC_ROOT = path.join(ROOT_PATH, 'collected_static/')
ADMIN_MEDIA_PREFIX = '/static/admin/'
STATIC_URL = '/static/'
# Additional locations of static files
STATICFILES_DIRS = (
path.join(ROOT_PATH, 'src/extra_static/'),
)
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)
Similarly, your templates can be loaded directly from an INSTALLED_APP:
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader'
)
TEMPLATE_DIRS = (
path.join(ROOT_PATH,'src/templates/'),
)
The two strategies above mean that templates and static content can live within their specific app directories. In Development, using contrib.staticfiles, static content can be served directly from your application folders. In production, there is a management command to collect all the app directory static content to /path/to/project/collected_static/, and you can point your web server at that directory to serve static content.
For pre-packaged libraries, using virtualenv and pip is a great idea. Otherwise, I like to keep libraries in a lib directory within the project root directory. It makes referencing the source, templates, and static content extremely convenient, rather than installing to site-packages (especially when not using virtualenv).
So, re-arranging your project structure:
webapps/
myproject/
apache/
bin/
lib/
collected_static/
uploaded_media/
myproject.wsgi
src/
templates/ # lib template overrides and site wide templates
base.html
lib_1/
nav.html
extra_static/
lib_1/ # libs that dont support django 1.3 static
js/
css/
settings.py
settingslocal.py # keep developer specific settings here
urls.py
manage.py
app1/
__init.py
static/
app1/
js/
css/
templates/
app1/
My designer doesn't want to go hunting everywhere (all over the python path) for template files. My template layout follows yours in that there is one template folder and all the apps go below that. Each app has its own base.html that extends basebase.html.
Here lately I've started following the pinax model of an apps folder, and all apps go in there. The reason for this is purely aesthetic since Wing shows me a tree, all my apps are clustered together in that part of the tree. What I didn't like was an app that sorted out alphabetically after templates or media or site_media. Scrolling up and down the tree slowed me down. By putting all the apps into one place in the tree, git commit -m "feature notes" apps checkins in the code changes too which is another plus.
webapps/
myvirtenv/
bin/
lib/
myproject/ <- Source control starts here
site_media/
collected_static/
js/
css/
img/
uploaded_media/
deploy/
myproject.wsgi
procmail scripts
apache site files # linked from /etc/apache2/sites-endabled
apps/
app1/
templates/ <- This should be here, but in practice I just leave in templates below
app1/
app2/
templates/ # lib template overrides and site wide templates
basebase.html <- I changed the name to help my designer
app1/
app2/
settings.py
gethostname()_local_settings.py # keep machine specific settings here
urls.py
manage.py
requirements
base.txt
project.txt
There were too many base.html files and talking about it was difficult, so basebase.html was born and we've been happy with that ever since.
I haven't had any static files that didn't work with the staticfiles app. I was using that app with 1.2. I haven't gone back and done the 1.3 static folders yet but I probably will in the next few months as things get worked on.
I got the requirements folder trick from pinax.
Create VirtualENV
git clone url
pip install -r requirements\base.txt -r requirements\project.txt
manage syncdb (if using sqlite, otherwise you have to do db creation tasks first)
symlink from /etc/apache2
reload apache config
Profit!
You've had some good thoughts here. My first reaction is to ask what that admin directory is doing? The admin is part of Django, and doesn't need a separate module - and the app-specific admin.py files need to live within their respective apps.
To answer your questions:
separating static and dynamic: this is done at the level of your web server configuration. In your case, your apache virtualhost conf needs to have an entry for the webapps/static directory, but not for anything else. The documentation has a good example.
If the apps really are completely decoupled from your project, then yes they could live outside it, as long as you put them onto the Pythonpath. One good way is to keep them in separate code repositories, and install them into your project with pip and virtualenv. However, I think you'll find that many of your apps will be project-specific, so live within your project directory.
Templates are very definitely dynamic content. If you serve them directly with Apache, they won't be parsed, so your users will see the code for the variable and block codes rather than the values.