Im looking for a reasonably simple toolset and workflow for incorporating Sass into my Django projects. Im predominantly backend focused and have just started investigating Sass, so bear with me.
My initial idea was to keep things simple by just using node-sass without trying to incorporate Gulp, django-pipeline or anything else initially.
My Django apps are usually structured such that I create a static/app/css folder in each app. One option I guess would be to now create an additional folder per app for scss files, ie: static/app/scss. The problem there would be that when running collectstatic in production, the scss files will be gathered as well. So should the scss files for each app be kept somewhere else? (I guess it doesn't really matter if the scss files are included when collectstatic runs?)
Next, outside of my Django project folders I would create a folder to install node-sass since I wouldn't want to install it globally and I don't want the node-modules folder inside my Django project or inside source control.
I guess the node-modules folder can be thought of like using a python virtualenv instead of installing packages globally?
Next, inside my Django project somewhere (not sure where?) I would have the package.json file containing a scripts section for every scss file I want compiled to css, eg:
"scripts": {
"compile:sass": "node-sass app1/static/app1/scss/style.scss app1/static/app1/css/style.css",
"compile:sass": "node-sass app2/static/app2/scss/style.scss app2/static/app2/css/style.css",
"compile:sass": "node-sass app3/static/app3/scss/style.scss app3/static/app3/css/style.css"
}
Lastly, I would just run compile:sass with the watch flag to constantly compile any files I work on and put them in the correct folders.
So my questions are, is the above setup a good approach (at least initially if im not ready to add yet another tool like Gulp etc to the mix)?
Also, how will I run compile:sass considering my package.json file will be in the Django project somewhere and the node-modules folder containing the node-sass installation will be somewhere else.
I help maintain node-sass, so I won't say not to use it. There is an alternate libsass-python that you might want to look at if you're working with Python though.
Check out the django-sass-processor package. It's simple to configure and use. I've used it a few times and have had good experiences with it. The package abstracts away Gulp, so you don't have to worry about it and streamlines the whole process.
Here's a tutorial on how to integrate django-sass-processor into a Django project.
Related
with the release of angular2 I actually encountered typescript, npm, ... for the first time, and I really appreciate its power, so I barely grasp the surface.
In the "development mode" I can find my way, but in the end:
Question:
I want to generate an independent folder that includes all necessary dependencies: js, css, html-files and is portable without needing npm, transpilers,... anymore. (So basically I want to copy this generated folder to a server and people can access the index.html as usually)
Problem
Setup
npm (as a module manager and build tool) npm as a build tool, npm as a build tool II
typescript (tsc as transpiler)
angular2 (with separated files for html, css), SystemJS
Needed Guideline
An (abstract) guideline for what steps to take in order to achieve the prescribed goal, namely a folder that has (all) the features and is build from the typescript files, (probably .scss-files,...) in a separate and self-contained way.
Probably I am searching for the wrong keywords but I have only found some fractions of my answers so far and I would really appreciate a list (of tutorials, or so) that I can stepwise go through. (Currently I feel lost)
I would have a look at the systemjs builder, using a build process such as gulp, gulp-inject to configure the index.html, and consitute the build like this:
build typescript files
bundle js files using systemjs in the build folder
build scss files (there must be a plugin for gulp) in the build folder
copy all html files in the build folder
inject dependencies in index.html
This is a raw answer to your question, untested, and from the top of my head, but I hope it can lead you to a solution. I have a little something in this repository.
I'm new to ember and after following a few guides, I've been playing around with ember apps. I'm using ember-cli to create an app, so I use
$ ember new 'app-name'
which creates the app as expected with the 'app' and 'dist' folder. But it also creates a lot of other files. I only discovered this while deleting the folder when the windows delete dialog box showed deleting more than 30000 files.
Is it that I'm doing something wrong that's causing unnecessary files to be created? Is there a way to avoid this?
You aren't doing anything wrong, a big portion of it is the dependencies and then the build process keeps a lot of temporary files around for reuse.
By the way, if you are developing in Windows, make sure you are running your command prompt as administrator, and that you've excluded the ember app from the virus scan, it really improves the build times.
It's not an issue with ember-cli itself, but how npm handles dependencies, since it has a hierarchical dependency system. You could try npm 3 (be warned, it's still beta - changelog), which tries to flatten out the dependencies better.
Another thing is checking if bower packages are adding any unneeded dependencies, like tests or raw source files (if they have pre built files). You could submit a PR to those projects by adding the ignore property in the bower.json file. See the spec here. Same with npm packages, which has a .npmignore file.
This is probably not what you wanted to hear, but in open source, we must all help each other. These are the bread crumbs of open source, and a great place to get started.
I'm to the point where I use many 3rd party apps, but I need to extend them. I'm trying to figure out the best way to modify an existing app. In the past I have just modified the code in the site-packages (knowing that it was bad), but that has its obvious downfalls.
Right now the closest I can get is to fork the github repo, and then I create an app in my project that I hook up to the forked github repo.
The problem is that what I'm forking is the project and not the app. So that means I have a structure like: project/app-project/app after I fork. Other things are also in the app-project directory such as LICENSE, AUTHORS etc.
Project
--App1
----Code
--App2
----Code
--ForkedAppProject
----LICENCE
----AUTHORS
----ForkedApp
------Code
If I just take the code inside the App directory, I can modify that, but then I'm losing all the source control for the Project (LICENSE, AUTHORS, etc) and that kind of defeats the purpose of forking the open-source app.
I want to set it up so that I am modifying the app code, but I am modifying so that my changes could contribute to the open-source project.
It's not necessary to place forked app inside your project. After forking and modifying you can add ForkedApp folder to PYTHONPATH or build your own package like this
python setup.py sdist
Then install it in your system/virtualenv and update INSTALLED_APPS.
The simplest and most convenient way to do this is to use pip --editable option. See “Editable” Installs in pip documentation.
I am working on an ecommerce site, based on django-lfs, and I am finding that I need to make a number of changes to the django-lfs core files... i.e. adding additional properties to models, updating views, adding url patterns etc. I started out placing django-lfs in my pythons site-packages path with the view that if i needed to make any changes to the code I would either re-define the url pattern (in the case where i needed to do something different in a view) or monkey patch code.
The thinking behind this was that i'd be able to keep the original django-lfs trunk clean and un-touched, allowing me to update it to the most recent version and then independently update / test the local overrides, subclassing and monkey patches written.
As you might have guessed, this is quickly becoming a bit of a nightmare to manage so i'm in desperate need of a cleaner and more stable solution.
The client project sits in a git repo and so i have been looking into submodules or subtree merging strategies... from everything i have read though, I am finding it difficult to find any definitive answers that are simple to understand (i'm relatively new to git).
In short, I need to be able to:
1) Include an external git repository into the main projects repo
2) Either make changes directly to the external repo (but have it push to the projects git repo and not to the external remote origin) OR create a local copy of the external repo and then periodically merge the external repo with the copied folder.
I have no idea how to achieve this though. to be clear, I would like to end up with the following folder structure:
PROJECT_NAME
MEDIA
TRUNK
APPS
django-lfs
EXTERNAL-REPOS
django-lfs
The lfs app in the external-repos folder should be able to pull down updates from the official (external) django-lfs repository and i should be able to freely make changes to tehe lfs folder stored in the APPS folder.
What i'm looking for, if at all possible, is a set of git commands / instructions to achieve the above and that make use of the real-worls folders outlined above, rather than using foo and bar references.
I hold my fingers tightly crossed and hope that someone out there can offer some advice :)
My quick take on this: either fork the project on bitbucket or github (depending on your preference of hg vs. git) and make a branch for your changes.
This will make it easier to keep your branch and the official master in sync.
Then, assuming you use pip+virtualenv, add the pointer to your repo/branch in your pip requirements file.
Unfortunately LFS uses buildout, so not quite sure what the equivalent of python setup.py develop would be (i.e. to install the package in your virtualenv site-packages but with links back to your repo so you can make changes without having to constantly run setup.py).
I've created a markdown extension file (called mdx_xxx.py) for a django project I'm working on but I can't really decide where to put it.
The documentation says that the file should reside on the PYTHONPATH and I've seen several blog posts inviting to just put the file in the root directory of the project.
However, that seems like an odd place to me as I would rather see it in the related application directory but then it's not on the PYTHONPATH anymore.
Could some experienced django programmer shed some light on this issue?
Thanks
Requiring extension files to live directly on the Python path, and not inside any package, is (IMO) an unfortunate limitation of the Python markdown implementation.
If your extension is very specific to your project, I think putting it in the project root is the best option available.
On the other hand, if your extension is reusable in other cases, I would package it up with a simple setup.py and install it into a virtualenv using pip, like I do with all my other dependencies.
Not everything should be in your project. This is a requirement, a dependency. You could still package them together, and you'll need to put this at the top level, I think. That basically means importable from the same location as the project itself. Personally, I push everything to a virtualenv, so its nice and clean. If you do the same, you're deployment process should include putting both your project and any dependencies safely into that virtualenv. Otherwise, to whatever location you have in path.
If you are using standard markdown library from pip (pip install markdown) now at version 2.3.1, the extension can be anywhere. You just have to provide dotted path to it. The old-style - having it directly on the PYTHONPATH in module prefixed mdx_ still works as well.
I have it in my app code:django_file_downloads.mdx_download.
To use it from django templates:
{% load markup %}
{{ variable|markdown:'django_file_downloads.mdx_download' }}