I'm new to django and working on a modern django/Wagtail CMS app that is seeded using the command python manage.py loadfixtures. It seems like loaddata is the more common command, and I'm finding it incredibly difficult to find any documentation on loadfixtures at all. Could anyone point me towards the difference? It appears under the [Core] section of "available subcommands."
As an aside, I'm essentially trying to dump and seed some static page data for the site.
loadfixtures is not a command that exists as standard on either Django or Wagtail, so it's presumably a custom command that's been added by a developer on your project, or possibly a third-party package you have installed. See Writing custom django-admin commands for documentation on how these are created - if you have a 'core' app as part of your project, you may well find the code for the command in core/management/commands/loadfixtures.py.
Related
In the django culture, I have encountered the concept of app reuse but not snippet reuse. Here is an example of what I mean by snippet reuse: I have a function getDateTimeObjFromString( sDateTime ), obviously you pass a string date time and it returns a python date-time object.
Back in the late 1980's or early 1990's, I was exposed to the idea of snippet reuse at a FoxPro developers conference. If you write code for a specific problem and find it is useful elsewhere in your project, move it to a project library. If you find that code is useful for other projects, move it to a generic library that can be accessed by all projects.
(At the FoxPro DevCon, they did not call it snippet reuse. I coined that term to make clear that I am referring to reuse of chunks of code smaller than an entire app. The FoxPro DevCon was long ago, I do not remember exactly what they called it.)
I read the most recent "Two Scoops of Django", and it does mention reusing snippets within a single project but I did not find any mention of the concept of snippet reuse across multiple projects.
I wrote and used getDateTimeObjFromString() long before I tackled my django app. It is in packages I keep under /home/Common/pyPacks. On my computers, I set PYTHONPATH=/home/Common/pyPacks, so every project can access the code there. The code for getDateTimeObjFromString() is under a Time subdirectory in a file named Convert.py. So to use the code in any project:
from Time.Convert import getDateTimeObjFromString
My django app downloads data from an API, and that data includes timestamps. It would be nice if the API sent python date time objects, but what you get are strings. Hence the utility of getDateTimeObjFromString().
This is just one example, there are many little functions under /home/Common/pyPacks that I found convenient to access in my django project.
Yes /home/Common/pyPacks are under version control in github and yes I deploy on any particular machine via git pull.
When working on my django project from a development computer, PYTHONPATH works, and I can import the packages. But then I tried running my django app on a server via wsgi.py -- PYTHONPATH is disabled. I can set PYTHONPATH both at the OS and Apache2 level, but python ignores it, the functions cannot import.
I do not want to bother with making my personal generic library an official python package under PyPI.
Does the django community expect me to copy and paste?
I arrived at a work around: make /home/Common/pyPacks a psudeo site-package by putting a "pyPks" symlink in the virtual environment's site-packages directory to /home/Common/pyPacks, adding "pyPks" to the INSTALLED_APPS, then changing all the import statements as follows:
original:
from Time.Convert import getDateTimeObjFromString
work around update:
from pyPks.Time.Convert import getDateTimeObjFromString
I also had to update all my generic library files to handle both absolute imports via PYTHONPATH and relative imports.
How to fix “Attempted relative import in non-package” even with init.py
Is there a better way to reuse snippets in a django project?
I am trying to debug an application that is written in Python 2. Problem is, before application can be run, it must be installed (according to the documentation) like this:
python setup.py develop
Application (Cuckoo Sandbox) then can be run like this:
cuckoo -d
With the new Python package developing and testing code now works slightly different than it used to be. As one
will first have to Install Cuckoo before being able to use it in the first place, a simple modify-and-test development
sequence doesn’t work out-of-the-box as it used to do.
Is it possible to somehow debug such application?
Later in the (unfinished) docs there is a mention of debugging web interface which I am not sure would get me to the code I need to debug and it also requires PyCharm Professional. I am using PyCharm Community but I am willing to use any other free IDE or debugger.
It will be difficult to debug if you are working only with compiled .pyo and .pyc files, which is all that you might have from an installed application. It is possible that the install includes some source files. You will have to figure out where it is installed, which is platform specific. Since many projects (including cuckoo) are open source, I would recommend cloning the Github repository and debugging from that.
I just started learning Pyramid using the official documentation and I found it very cool so far.
Unfortunately, while the basic one-file app is really simple and straight, I'm having an hard time trying to understand how a "serious app", generated using the pcreate scaffolding command (alchemy in my case), is supposed to be handled.
For example:
is setup.py mandatory or can I just use requirements.txt as I'm used to do with Django in order to install dependencies?
if I have to rely on setup.py am I supposed to execute python setup.py develop each time I create/delete a new file (since I saw them listed in SOURCES.txt)?
In settings.ini how "use" (under [app:main]) works? (can I "bypass" the egg-info which is it pointing to and "bootrsapping" the app in an alternative way?)
There are several tutorials that addresses all these topics, and provide references to further relevant reading for each step along the way. I suggest starting with the Quick Tutorial.
To answer your bullet points in order:
setup.py is a standard for installing Python packages and dependencies and testing your app.
If you need to install more packages as a result of your changes, then yes. EDIT: It is now recommended to use pip install -e . for installing more packages. Also while developing, you can use pserve development.ini --reload which will monitor file changes and restart the server for you.
For more information about the meaning of the use = egg:MyProject, see Entry Points and PasteDeploy .ini Files. There are many ways to configure Pyramid apps including Application Configuration and Advanced Configuration.
You chose Pyramid, the best Python web microframework, a very choice! Here are some pointers for further insight. Actually your question is not specific to Pyramid, but generally how Python packages and applications generally work.
is setup.py mandatory or can I just use requirements.txt as I'm used to do with Django in order to install dependencies?
It is not. You can use requirement.txt. setup.py install_dependencies is mainly for libraries. For more information read blog post Declaring dependencies in Python.
if I have to rely on setup.py am I supposed to execute python setup.py develop each time I create/delete a new file (since I saw them listed in SOURCES.txt)?
It's not necessary.
In settings.ini how "use" (under [app:main]) works? (can I "bypass" the egg-info which is it pointing to and "bootrsapping" the app in an alternative way?)
Please see the other answer regarding Paster and Entry points.
Every time I start a shell using python manage.py shell, I want a few lines to be executed automatically. (In my case it would be a few import lines in the style of import django, my_app.)
How do I do this?
The package django-extensions does what you want. If you pip install django-extensions, and you can add the app as always (in your app list, then run syncdb), then you get a command called shell_plus.
That command loads all your models automatically if you run python manage.py shell_plus. Really handy! If you combine that the power of IPython you get a nice environment to interact with your models using the django ORM.
More information:
For the package: https://github.com/django-extensions/django-extensions
For the docs on shell_plus: http://pythonhosted.org/django-extensions/shell_plus.html
For the docs of django-extensions: http://pythonhosted.org/django-extensions/
Hope this helps. It might be less work than writing start-up scripts. As an extra django-extensions gives you great functions like graph_models (which can give you a png drawing of your database) and show_urls.
I ended up monkeypatching IPython.frontend.terminal.embed.InteractiveShellEmbed.__call__ to add the definitions I wanted. (I know many people are opposed to monkeypatching but I find it to be a good solution in this case.)
I'm building a Django app, which I comfortably run (test :)) on a Ubuntu Linux host. I would like to package the app without source code and distribute it to another production machine. Ideally the app could be run by ./runapp command which starts a CherryPy server that runs the python/django code.
I've discovered several ways of doing this:
Distributing the .pyc files only and building and installing all the requirements on target machine.
Using one of the many tools to package Python apps into a distributable package.
I'm really gunning for nr.2 option, I'd like to have my Django app contained, so it's possible to distribute it without needing to install or configure additional things. Searching the interwebs provided me with more questions than answers and a very sour taste that Django packing is an arcane art that everybody knows but nobody speaks about. :)
I've tried Freeze (fails), Cx_freeze (easy install version fails, repository version works, but the app output fails) and red up on dbuilder.py (which is supposed to work but doesn't work really - I guess). If I understand correctly most problems originate form the way that Django imports modules (example) but I have no idea how to solve it.
I'll be more than happy if anyone can provide any pointers or good resources online regarding packing/distributing standalone Django applications.
I suggest you base your distro on setuptools (a tool that enhances the standard Python distro mechanizm distutils).
Using setuptools, you should be able to create a Python egg containing your application. The egg's metadata can contain a list of dependencies that will be automatically installed by easy_install (can include Django + any third-party modules/packages that you use).
setuptools/distutils distros can include scripts that will be installed to /usr/bin, so that's how you can include your runapp script.
If you're not familiar with virtualenv, I suggest you take a look at that as well. It is a way to create isolated Python environments, it will be very useful for testing your distro.
Here's a blog post with some info on virtualenv, as well as a discussion about a couple of other nice to know tools: Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip
The --noreload option will stop Django auto-detecting which modules have changed. I don't know if that will fix it, but it might.
Another option (and it's not ideal) is to obscure some of your core functionality by packaging it as a dll, which your plain text code will call.