/build dir on a Yii2 app (advanced template) - build

I'm working on the frontend of a Yii2 app and I want to implement Grunt to perform a small number of tasks like compiling my .sass files and concatenate and minify .js files.
I know I don't need to push the node-modules folder to the repo, anyone who wants it can just npm install as I have it packaged properly, so there's no need for my team mates to have the node-modules folder if they don't touch the frontend side of the app whatsoever. My question is, should i push my build folder, where i have my .sass and .js files before they're compiled? Or better yet, I know I don't NEED to push it but should I want it there as a backup in case i want to pull the project from a different computer or so? Is there any downside to having the /build dir on the repo?
I don't want to clutter the repo for everybody else, yet i feel like i should have it there as a backup, or even if someone else wants to edit the files, is this common practice?
Also, to anyone familiar with the yii2 advanced template, where exactly should said /build folder go?
Thank you.

Related

including foundation with sass in a django project

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

Django Deployment Advice

I have a multi-step deployment system setup, where I develop locally, have a staging app with a copy of the production db, and then the production app. I use SVN for version control.
When deploying my production app I have been just moving the urls.py and settings.py files up a directory, deleting my django app directory with rm -rf command and then doing an svn export from the repository which creates a new django app directory with my updated code. I then move my urls.py and settings.py files back into place and everything works great.
My new problem is that I am now storing user uploads in a folder inside of my django app, so I can't just remove the whole app dir anymore or I would loose all of my users files.
What do you think my best approach is now? Would svn export --force work, since it should just be overwriting all of my changed files? Should I take an entirely new approach? I am open to advice?
You may want to watch this presentation by Jacob. It can help you improve your deployment process.
I use Bitbucket as my repo and I can simply perform push on my Dev box and run pull/update on Stage/Prod box. Actually I don't run them manually, I use fabric to do them for me :).
Your could use rsync or something similar to backup your uploaded files and use this backup when you deploy your project.
For deployment you could try to use buildout:
http://www.buildout.org/
http://pypi.python.org/pypi/djangorecipe
http://jacobian.org/writing/django-apps-with-buildout/
For other deployment methods see this question:
Django deployment tools
You can move your files to S3 servers (http://aws.amazon.com/s3/), so you will not ever have to care about moving them with your project.

How do clone a Mercurial repository into a directory that already exists?

I have a client's Django project that I'm developing locally, using Mercurial for version control. I push my local repository to my personal remote server (where I keep all my projects) and then when I come to deploy it (on whichever web server) I clone that respository there from my personal server.
This works fine on most servers (where I have total control) but I have a few projects where I'm deploying on to WebFaction. WebFaction is great, but a little unusual with it's setup, as I need to first declare the Django project as an 'application' through their control panel. This creates a few things automatically, such as an 'apache2', 'myproject', etc folder. It's this same folder though where I want to clone the repository from my personal remote server. Doing the usual hg clone command just doesn't work though as it says the destination folder already exists. There isn't much I can do about the contents of this folder really, so I need to work around this.
I'm not an expert at Mercurial and the only way I could seem to work it out is clone it to another folder and then moving all the contents (including the .hg) into the actual folder I want. This seems silly though...
I'm using Mercurial v1.6.2 (installed through easy_install). Could anyone share some light on this?
Many thanks.
Copying just the .hg dir definitely works, but you could also do a hg init and then hg pull http://remote/repo. A repo that has just been initalized has only the 000000000000000 changeset, so you can pull from any repo without getting the "unrelated repos" warning. This is essentially the same as hg clone --pull with a manual init.
You can copy just the .hg folder, then revert or update to tip. E.g.:
cp -a src/.hg dest/
cd dest
hg up -C
you can either move the folder after the fact, or you can just make a symlink to it. my webfaction directory is actually symlinked, so i know it works fine.
In the main, it looks like you might be trying to use Mercurial as an installation manager which is certainly not its design goal.
If I am reading you correctly, part of your source repository should be something like make deploy which puts the files into their proper places. Put another way, having a repository clone (in .hg) in your deployment directory seems odd and trouble-prone.

Good way to deploy django project to a testing sever?

This is specific to my current project. But maybe the answers will reveal some more generic solutions.
Here is the situation:
I develop django project on my Windows box
I use SVN to commit to a SVN repository
while developing I use development server that comes with django
There is a testing server (apache) that runs somewhere else, and everytime i finish something I need to manually copy my work via WinSCP/Putty and make sure it works on testing server
Testing server is accessible for our testers to use and test and report bugs
I would like to automate this process as it is very painful. It involves me to export the whole repository, copy to the testing server, get rid of the pyc files, sometimes restarting apache, use the correct settings.py (usually some renaming).
I would like to for the testing server to automatically retrieve new files after each SVN commit. I could write a custom script to do all this stuff, but something tells me that there are some easy-to-use solutions I could use to change my workflow to make things less painful.
One extra bonus. There is a designer that works on HTML/CSS on the templates directly on the testing server. I need to check whether he made changes and I transfer them to my computer and subsequently to SVN rep. My boss thinks it's too dangerous to give him SVN access. Any ideas to help me out with this, also?
deployment:
I would say its better to do the deployment the same way you do for the production. Fabric is a good solution.
SVN way:
If you want to do it in the SVN way, create a branch called testing, once you have a working version of your code and ready for testing merge the development branch to the testing branch. Make sure you have permission on the testing branch to restrict everyone from merging to the test branch. After merging the test team should take a update to a specific version.
.pyc
It unnecessary to manually remove pyc files you can add a svn hook which can ignore the pyc files on commit. Create a file .svnignore
*.pyc
and run this command
svn -R propset svn:ignore -F .svnignore .
If you’ve already got yourself into the mess of versioning your compiled files, then you can do either of these things.
find -name "*.pyc" -exec svn revert {} \;
find -name "*.pyc" -exec svn delete {} \;
Django settings file
You can set the environment variable through which django can take up corresponding settings file. Django set env
Designer
well designer working directly on the test server is not a bonus point. :) its a headache. In a ideal environment no one should touch the code in the testing server. Create a separate branch for the designer or he can commit to the dev branch which all the developers can merge.
One option is to create a read only svn user and have it checkout the svn repository on the apache server. Then to do a build you run 'svn update'. You can check if the designer modified files by doing a 'svn status'.
If your svn repository is on the same machine as your qa django instance you could use a post-commit hook to have it svn update after each commit, and bounce apache if needed. See http://subversion.tigris.org/faq.html#website-auto-update

What is a good way to package django apps?

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".