In Django 1.4 and above :
There is a new file called app.py in every django application. It defines the scope of the app and some initials required when loaded.
Why don't they use __init__.py for the purpose? Any advantage over __init__.py approach? Can you link to some official documentation for the same?
Even though the details are wrong (there's no app.py in new Django projects), the question is still valid.
__init__.py is imported implicitly when importing a sub-module. So if something in __init__.py executes automatically with side effects, you might run into unintended consequences. Doing everything in app.py incurs a longer import, but separates package init from app init logic.
As all the links you have provided clearly show, this is nothing at all to do with Django itself, but a convention applied by the third-party app django-oscar.
Sometimes when people are learning a new technology they copy the file names as they saw on a tutorial. Some even continue using those either out of habit, out of thinking that is what they need to do, or they just like it. That might be why you see app.py so often.
Here is an example of one such tutorial https://realpython.com/blog/python/flask-by-example-part-1-project-setup/
there they are building "flask by example" and the instructions give you this command
touch app.py .gitignore README.md requirements.txt
So of course now you have that file. This is the same for javascript projects where they might list scripts.js or css tutorials where they use styles.css.
Related
Where should utility functions live in Django? Functions like custom encrypting/decrypting a number, sending tweets, sending email, verifying object ownership, custom input validation, etc. Repetitive and custom stuff that I use in a number of places in my app. I'm definitely breaking DRY right now.
I saw some demos where functions were defined in models.py, although that didn't seem conceptually right to me. Should they go in a "utilities" app that gets imported into my project? If so, where do they go in the utilities app? The models.py file there?
Thanks for helping this n00b out.
UPDATE: Let me be even more specific. Say I need a function "light_encrypt(number)" which takes the param "number", multiplies it by 7, adds 10 and returns the result, and another function "light_decrypt(encr_number) which takes the param "encr_number", subtracts 10, divides by 7 and returns the results. Where in my Django tree would I put this? This is not middleware, right? As Felix suggests, do I create a python package and import it into the view where I need these functions?
Different question but same answer:
My usual layout for a django site is:
projects/
templates/
common/
local/
Where:
projects contains your main project and any others
common contains things you may share across sites, or are at least not project-specific, like if you need to download django-profile and django-registration rather than having it directly in python/site-packages
templates contains just that
local contains things that are going to be specific to the current machine, so that you can have properly separated data, like database location and password - I then soft-link the machine-specific versions (say "machine1-localconfig.py") to local/localconfig.py and then can "import localconfig" in settings.py
I generally put middleware that's project-specific inside a project, and middleware that's not project-specific in common/middleware/
make sure to add the templates directory to the right place in settings (or most probably, localconfig.py and then import it in settings), and makse sure to add the projects, common, and local directories to your PYTHONPATH.
OK, after reading the comments and answer here I've decided to create a directory called "common/util/" inside my project directory. Within that I have a file "__ init__.py" where I have my little helper functions.
I guess if the file gets too big, I'll then split out the functions into individual .py files in common. So now, my project structure looks like this. Please correct if I'm making any poor choices, I'm early enough in development that I can fix it now while it is still easy to do so!
myproject/ (Django project)
common/
util/
__init__.py (helper functions)
middleware/ (custom middleware)
templates/ (project templates)
myapp/
fixtures/ (initial data to load)
migrations/ (south migrations)
urls/
views/
admin.py
forms.py
models.py
test.py
public/ (static stuff not served by Django)
media/
css/
img/
js/
lib/
Here is another way to do it:
If the utility functions can be a stand-alone module
and you are using a virtualenv environment for your django app
then you can bundle the functionality as a package and install it in your virtualenv.
This makes it easy to import where ever you need it in your django app.
It depends whether the functions are project or app specific.
The other answers are already addressing where to place it for project specific functions. More precisely, in a folder called common in the root of the project.
If we are talking about app specific, then I'd simply place it inside of the app in a file named utils.py, like
myproject/ (Django project)
common/
util/
__init.py__ (project app specific functions)
myapp/
migrations/ (myapp migrations)
utils.py (myapp specific functions)
views.py
admin.py
forms.py
models.py
test.py
I know this question has been asked in a lot of places, but none of them really seem to answer my question.
I am creating a standalone application in python, my current project structure is like so:
Project/
utils/
log.py
api/
get_data_from_api.py
main.py
I would like to have a set up similar to django, in which I can refer to any file by using a Project.<package> syntax.
For example, if I wanted to access my log module from my get_data_from_api module, I could do something like this:
get_data_from_api.py
import Project.utils.log
# Rest of code goes here...
However, I can't seem to get that to work, even when I added an __init__.py file in the root directory.
I read somewhere that I should modify my PYTHONPATH, but I would like to prevent that, if possible. Additionally, django seemed to pull it off, as I couldn't find any PYTHONPATH modification code in there.
I really appreciate the help!
Post Note: Where would tests fit in this file structure? I would like them to be separate, but also have access to the entire project really easily.
You need to add __init__.py to every directory that you want to treat as a Python package, not just to the root directory.
Post Note: Where would tests fit in this file structure? I would like
them to be separate, but also have access to the entire project really
easily.
You could place your tests in the Project directory itself, parallel to api and utils.
I ended up using a file structure like the following:
src/
main.py
project/
api/
get_data_from_api.py
util/
log.py
test/
That way, because I am running the main.py file, from anywhere in the program, I can just do import project.<package>.<module>. For example, I can just do this:
get_data_from_api.py
import project.util.log
# Rest of code goes here...
And everything works!
If I'm completely shooting in the dark please let me know, I'd much rather be wrong now then hundreds of hours into the project!
It may be helpful if you look at these three tutorials. It may not completely solve what you imagined, but it will certainly give you an idea or background on how to do it.
How to structure a Flask-RESTPlus web service for production builds - GitHub Code
Structuring Your Project - GitHub Code
Clean architectures in Python GitHub Code
They have already written about Django, so you can see the details at: Best practice for Django project working directory structure.
I'm developing a rather complex desktop application using wxPython framework. At this point, app already contains a dozens of modules: libraries, UI modules, util modules.
Project looks like this:
MyApp/
__init__.py -- empty
main.py
util/
__init__.py -- empty
lib1/
__init__.py
lib2/
__init__.py
gui/
__init__.py -- empty
window1.py
Unfortunately with current project structure I cannot use absolute imports, because python MyApp/main.py will fail with error like ImportError: No module named MyApp.gui
To overcome this, I'd like to make MyApp an executable package:
my_app/
__init__.py -- empty
__main__.py
util/
__init__.py -- empty
lib1/
__init__.py
lib2/
__init__.py
gui/
__init__.py -- empty
window1.py
Now application can be started using python -m my_app
Everything seems ok so far… but I am full of doubts, because no-one uses such approach. If you take a look at demo that comes with wxPython you'll see that it's mostly flat project.
I'm definitely not the smartest one therefore I'm missing something simple and obvious why no-one uses such approach.
Maybe I should just stick with subfolders or flat project structure? Maybe absolute imports don't worth such changes?
If I were you, I would look at some of the wxPython applications that are out there and see how they do it.
Editra - a text file editor + more
Chandler project
Phatch
Or even the wxPython demo package.
Putting most of it in a package namespace is the best way to go, since you can also take advantage of byte-code caching and setuptools/Distribute can easily install it. Then you just provide a simple top-level script to load the main module and run it.
Something like:
#!/usr/bin/python
import sys
from MyApp import main
main.main(sys.argv)
Just name that something like myapp and install in /usr/local/bin (or somewhere on PATH). All it does is import the main module and run the main function (or class).
You seem to understand why it's a good thing to have it under a single package. So I think I'll just go over this briefly:
You get to organize your project better. If you have multiple modules responsible for different things, you don't fear having a conflict with some other library. So it will basically act as a simple namespace.
You get the benefit of updating via easy_install or whatever. I'm not sure it's really a big plus though.
It can be easier to extend with plugins, whether voluntarily allowing them, or just leaving place for some tweaking on the user-side.
I'll just give you some examples which use this approach, I think mainly for the plugins approach:
Exaile: music player, which allows you to add plugins through this structure, and notice also the gui is in a separate package. Not sure why, but it definitely makes the separation of UI (GTK, but does not matter) clear.
I'll just advertise myself here :) wxpos: it's one of my projects, if you want to take a look at my approach with wxPython as an example.
There are more than I can think of, I'm sure I've seen it somewhere else too.
Where should utility functions live in Django? Functions like custom encrypting/decrypting a number, sending tweets, sending email, verifying object ownership, custom input validation, etc. Repetitive and custom stuff that I use in a number of places in my app. I'm definitely breaking DRY right now.
I saw some demos where functions were defined in models.py, although that didn't seem conceptually right to me. Should they go in a "utilities" app that gets imported into my project? If so, where do they go in the utilities app? The models.py file there?
Thanks for helping this n00b out.
UPDATE: Let me be even more specific. Say I need a function "light_encrypt(number)" which takes the param "number", multiplies it by 7, adds 10 and returns the result, and another function "light_decrypt(encr_number) which takes the param "encr_number", subtracts 10, divides by 7 and returns the results. Where in my Django tree would I put this? This is not middleware, right? As Felix suggests, do I create a python package and import it into the view where I need these functions?
Different question but same answer:
My usual layout for a django site is:
projects/
templates/
common/
local/
Where:
projects contains your main project and any others
common contains things you may share across sites, or are at least not project-specific, like if you need to download django-profile and django-registration rather than having it directly in python/site-packages
templates contains just that
local contains things that are going to be specific to the current machine, so that you can have properly separated data, like database location and password - I then soft-link the machine-specific versions (say "machine1-localconfig.py") to local/localconfig.py and then can "import localconfig" in settings.py
I generally put middleware that's project-specific inside a project, and middleware that's not project-specific in common/middleware/
make sure to add the templates directory to the right place in settings (or most probably, localconfig.py and then import it in settings), and makse sure to add the projects, common, and local directories to your PYTHONPATH.
OK, after reading the comments and answer here I've decided to create a directory called "common/util/" inside my project directory. Within that I have a file "__ init__.py" where I have my little helper functions.
I guess if the file gets too big, I'll then split out the functions into individual .py files in common. So now, my project structure looks like this. Please correct if I'm making any poor choices, I'm early enough in development that I can fix it now while it is still easy to do so!
myproject/ (Django project)
common/
util/
__init__.py (helper functions)
middleware/ (custom middleware)
templates/ (project templates)
myapp/
fixtures/ (initial data to load)
migrations/ (south migrations)
urls/
views/
admin.py
forms.py
models.py
test.py
public/ (static stuff not served by Django)
media/
css/
img/
js/
lib/
Here is another way to do it:
If the utility functions can be a stand-alone module
and you are using a virtualenv environment for your django app
then you can bundle the functionality as a package and install it in your virtualenv.
This makes it easy to import where ever you need it in your django app.
It depends whether the functions are project or app specific.
The other answers are already addressing where to place it for project specific functions. More precisely, in a folder called common in the root of the project.
If we are talking about app specific, then I'd simply place it inside of the app in a file named utils.py, like
myproject/ (Django project)
common/
util/
__init.py__ (project app specific functions)
myapp/
migrations/ (myapp migrations)
utils.py (myapp specific functions)
views.py
admin.py
forms.py
models.py
test.py
I have a python/django application that runs on the google app engine.
My views.py file has some imports...
from commands.userCommands import RegisterUserCommand
from commands.accountCommands import CreateNewAccountCommand, RenameAccountCommand
These imports work fine on my development environment (local machine). But when I upload to the google app engine, views.py fails with a "Could not import views. Error was: No module named userCommands" error.
Any idea why I can't import my commands.userCommands module?
My file structure looks as follows...
- app.yaml
- urls.py
- views.py
- etc...
- commands/__init__.py
- commands/userCommands.py
Note: I did try to append my application name to the module name/path. No luck.
Note: I did do an update with the --noisy argument, and it does appear to upload my commands folder successfully.
You could be running into a clash with Python's own commands module (which doesn't have submodules like yours) -- naming your own modules and packages in ways that are meant to hide ones in the standard library (just like naming your variables in ways that are meant to hide builtin names, like list or file) is always a perilous undertaking, even though it "should" work there's always potential for confusion.
Could you try renaming that commands package and its uses to something unambiguous and free from danger, such as mycommands, and see if that just makes the problem disappear? If that's the case you can then open a ticket on GAE's tracker (because it would show a minor but undeniable bug in GAE's runtime) but meanwhile your problem is solved!-) If the problem stays, ah well, at least we've eliminated one likely cause and can keep digging...
The __init__.py files are required to make Python treat the directories as containing packages, so you need a
commands/__init__.py
file in your directory structure. See http://docs.python.org/tutorial/modules.html.