I have a django project which is installed by customers on their servers. I've got a few more apps which are optional plugins of functionality that can be installed/uninstalled.
I'd like a simple way to package these plugin apps to make the install/uninstall painless. I dont want them to copy the template files to one directory, app to another one, media to a third one and so on. I would prefer that they need not edit settings.py, though its okay if it can't be helped.
The ideal situation would be if they could simply unzip to a location on the python path (maybe a special plugin directory?), and delete it to uninstall. Is there an easy way to package the apps so that they can be installed this way?
I'll skip over discussion of Python packaging (distutils, setuptools, pip, etc), since it sounds like you'd prefer using simple zip files or tarballs. I'll address the "pain points" you mentioned one at a time:
Template files: As long as you have 'django.template.loaders.app_directories.load_template_source' included in the TEMPLATE_LOADERS setting of your projects, you shouldn't have to worry about this one. Each of your apps can have a "templates/" subdirectory, and templates in there will be loaded just as if they were in your project-wide templates directory.
Media files: App media is a pain. For development, you can use a custom serve_media view that operates similarly to the app_directories template loader (looks for media in each app). In production, you have to either copy the files, use symbolic links, or use webserver-level aliases. There are several utility apps out there that try to smooth over this problem; I now use django-staticfiles.
Editing settings.py: No simple way around this one. For its models, template tags, management commands, etc to work, an app has to be listed in INSTALLED_APPS. What you could do is write some custom code in your settings.py that lists the contents of a certain directory and dynamically adds the packages it finds there to INSTALLED_APPS. A little bit dangerous (think carefully about who has permissions to place files in that directory, because they have the keys to your kingdom), and new files there will only be detected on a server reload, but it should work.
I think if you put together those solutions, it's possible to achieve your ideal situation: unzip to install, delete to uninstall.
Editing settings.py: Your plugin can read its settings from its own settings file in its own directory. They'd only need to edit the root settings.py to add/remove the plug-in path from "INSTALLED_APPS".
Related
Tell me, is it possible to install django-shop on Divio servers?
How can I do that?
I can’t imagine how this can be done, because the structure of files in divio is different from the structure of ordinary django projects
There's nothing special at all about the structure of Django projects (or any other projects) in Divio applications.
If using the default Aldryn Django project type, then it starts with a particular project layout, but you are free to use this or not. Projects run in Docker and at the Python/Django level can be configured as you please.
See How to install Python dependencies in a project, and additional information on managing settings with Aldryn Django.
I trying to "debianization" my small programm. My programm has "templates" directory. This folder contains the files the user is working with. The user will also store their files in this directory. But all these operations are done by my program, and I want to hide this folder in the "HOME" directory. But I do not understand how this can be done with the debianization of the package? I can create a bash script that will create the necessary folders for me, but how can I transfer an already prepared folder with files to a package?
A deb package can only install things in /usr and configuration files in /etc. You generally should not modify users' home directories during installation; packages might create customizations for individual users if and when they interact with the installed package e.g. by running an installed utility for the first time.
Obvious workarounds such as looping over all individual users' home directories from the postinst or configure script violate Debian policy, create unpleasant surprises, and obviously don't work for users whose accounts are created after the package was installed.
I have a django project under a virtualenv.
I included the django-zurb-foundation 5.3.0 package to use foundation but this version only include static css files.
It's my first time using django and normally i use foundation with sass using bower and grunt.
How can i do to use the sass version of foundation?
What should be the files tree?
UPDATE
i installed django compressor and i got it work on local, it works perfectly, but i cannot get it to work on my production server:
on local env i have a CACHE folder with the css static files in it and the html page call correctly the file from there.
On the prod site instead, it doesnt create the CACHE folder and it doesnt render the path to it and it keeps the path to the scss file.
What am i doing wrong?
It seems like compressor isnt working on the prod server, i'm afraid i'm doing something wrong with django settings.py since i'm new to it.
any help?
I have heard of a few people using django-bower with foundation, personally I have not played with it but its worth looking into if you have not already.
I really can't find a reason to use a third party Django application to do that, using front-end frameworks like foundation or Bootstrap is as simple as compiling the less or sass source files to a css file and include it in your html (<link rel="stylesheet"...).
With Django you can use Bower and Grunt without any problem because they're independent and totally configurable to fill your needs. What I do with bower is to create a .bowerrc file at the same level of the bower.json file with the directory setting pointing to the main static folder, something like:
{
"directory": "my_django_app/static/bower_components"
}
Talking about the django-compressor app all that I can say is I don't recommend to use it in a production environment, it has some performance problems and personally I prefer the static files to be responsibility of the front-end dev instead of the back-end dev. For example you will need to have source maps for your javascript for debugging purposes and I don't remember if it's possible with this plugin.
Instead of using the django-compressor you can use a grunt plugin to to it, I've done one that may help you to do so: https://www.npmjs.org/package/grunt-django-compressor
I have a Django app running on Heroku that uses Bower to manage front-end dependencies. These dependencies, along with my application, are optimized with RequireJS and served up using Amazon S3. Is there an easy way for me to know what files in my bower_components directory can be safely deleted from my static file server?
I would leave your bower_components folder in your root, untouched and ignored by your VCS. Then use something like Grunt to copy the selected files into a scripts folder somewhere and then use RequireJS to build those.
This allows you to easily update your bower components and prevents you needing to commit needless repository cruft into your repo.
You can use the Grunt concat or copy task to do this or try the grunt-bowercopy task that will also run a bower install for you
The best solution I have found so far is to use django-pipeline to process front-end assets. django-pipeline will:
...help you by excluding much of the extra content that Bower includes
with its components, such as READMEs, tests and examples, while still
including images, fonts, CSS fragments etc.
(from Using Pipeline with Bower)
I am finally going to start using virtualenv for my Django projects on my development machine. Before I start I want to know if there are any special considerations for dealing with my existing projects. My presumed workflow is something like:
make a new virtualenv
activate the new virtualenv
Install Django in there
pip install all the packages I know I need for my existing project
copy my Django project files, app files, and git files into the project folder within the virtualenv.
Edit
6. make requirements file for deployment
This is obviously very simplified but are there any steps or considerations I am fundamentally missing? Is git going to be happy about moving? Also is it best practice to have a separate virtualenv for each Django project?
I know this is not a typical code problem, but I hope those that know more than I do can point me in the right direction.
Many thanks.
I don't see any big issue on migrating your projects and I think your 5-steps plan is correct, in particular, for steps 3/4/5 (I'd merge them), you can handle project dependencies with pip, possibly using requirement files.
Requirement files are plain text files telling to pip which packages have to be installed in your virtualenv, included your git-tracked projects which eventually can be deployed in your virtual environment as development eggs (they bring with them version control infos).
Once you have a req file, it's a matter of:
pip install -r file.req
to have all needed packages installed in your env.
As you can see from virtualenv docs, a typical req file would contain something like:
django==1.3.0
-e git://git.myproject.org/MyProject.git#egg=MyProject
I usually keep each project in its own virtualenv, so I can deploy it to the production server the same way I do for local development.