torchbox / django-libsass Goto Github PK

On October 5th libsass was updated to 0.19.3, I am not exactly sure what it is but it manage.py compress hangs until libsass==0.19.2 is specified as a pip requirement. Looking into it deeper today.

'compress'. Did you forget to register or load this tag?

{% compress css %}
    <link rel="stylesheet" type="text/x-scss" href="{% static "myapp/css/main.scss" %}" />
{% endcompress %}

Would be wonderful if you could release the 0.3.0 version with the new libsass settings on PyPI!

First off, I love the library.

I am looking to deploy with django + whitenoise, and I noticed that if I don't already have the scss compiled when the server starts, the file server (in this case, whitenoise) does not notice the compiled, now cached, css file.

Now, at the root of the problem this is due to how whitenoise handles its dependencies (cache, only static that exists at launch time are recognized), however I am wondering how you recommend using this to get around that issue (possibly a different type of static file serving?). I can get around this with WHITENOISE_AUTOREFRESH = True which allows it to check any new staticfiles that show up, but it is not recommended to do this.

I also tried using s3 to host my staticfiles, however after digging deep into the dependency chain, one of them (I don't remember which anymore) specifically checks if the default store is network and if so, don't create the file there. It instead just creates it locally and without a collectstatic is never pushed over to the static root.

In every scenario I tried I would have to either manually intervene after each css has been compiled (by either restarting the server or running collectstatic). Any guidance would be appreciated.

Apparently, the import path of the static() method changes in Django – please adjust django-libsass accordingly (not only to be future-proof, but also to save me from the amount of warnings my Django projects produce atm 😉 )

django_libsass.py:19: RemovedInDjango30Warning: django.contrib.staticfiles.templatetags.static() is deprecated in favor of django.templatetags.static.static()

I'm trying to use django-libsass with tools like Bourbon, Compass and Breakpoint and I keep getting errors saying

CompileError at /

/vagrant/projects/wellingtoncordeiro/assets/css/main.scss:25: error: file to import not found or unreadable: 'bourbon'

I'm not sure what the solution is, if there is one but it appears that sass isn't able to follow the import paths to the installed libraries.

When using the compress tag to compile a main scss files, only scss codes written in the main file are compiled ignoring all imported scss files. I experienced this while importing zurb foundation 6 scss files to customize.

{% load static %}
    {% load compress %}
    {% compress css %}
    <link rel="stylesheet" href="{% static "homepage/css/custom.scss" %}" type="text/x-scss" media="screen">
    {% endcompress %}

In the above, custom.scss contains other scss files imported from foundation 6 css framework

Importing raw css files is not working since the libsass 0.14.3 release.
https://github.com/sass/libsass-python/releases/tag/0.14.3

It seems like django-libsass needs some update to work properly again since the libsass 0.14.4 release fixed this situation providing a new way to import raw css files.
https://github.com/sass/libsass-python/releases/tag/0.14.4

Should I include anything in my installed apps?

What is the suggested way to set this up?

I have 64bit python installed, which means I needed the 64 bit version of libsass-python.
I got it and installed it, but was still presented by the

"ImportError: DLL load failed: %1 is not a valid Win32 application"

error, which comes from django-sass not using the libsass-python installation I had input

I've resolved this issue locally but by installing libsass-python outside of the virtualenv.

I'm not sure why it happens but let me describe an issue I've faced. So, I installed the newest package versions:

• libsass-0.9.2
• django-libsass-0.6

After I detected on my site that fonts hadn't been downloaded due to wrong urls, therefore I checked css files and found font urls like:

url('https://d66cvws976y93.cloudfront.net/static/bower_components/bootstrap-sass/assets/fonts/bootstrap"glyphicons-halflings-regular.eot');
url('https://d66cvws976y93.cloudfront.net/static/bower_components/bootstrap-sass/assets/fonts/bootstrap"glyphicons-halflings-regular.eot?#iefix') 

Note, " in the middle of the urls, that's why I went back to the previous versions of packages that work for me:

• libsass-0.8.3
• django-libsass-0.4

Hi

When I enable this I get segmentation fault python manage.py run server

I’m using django-libsass, installed version 0.7 from PyPI.

In django_libsass.py, there’s an import that fails in Django 3:

from django.templatetags.static import static as django_static

From the release notes of Django 3: “The staticfiles and admin_static template tag libraries are removed.”
Please provide support for using django_libsass with Django 3.

This issue was posted in django-compressor. I'm not sure which library would be best to provide this support.

The problem is that I can't use a variables.scss separate from other dependencies.
I've got around this by using a main.css and lots of @imports in there, which works just fine and is clean enough to me, but django-compressor doesn't notice when files other than main.scss are changed, requiring a server-restart for any scss that were @imported.

Webassets solved this by setting a SASS_AS_OUTPUT flag that concats files before processing them.

Do you think it's best solved in django-compressor or here?

Related: django-compressor/django-compressor#226

When precompilers (such as django-libsass) are in use but compression is disabled, files are served from /static/CACHE/ but django-compressor's CssAbsoluteFilter does not run. As a result, relative paths within the CSS are treated differently depending on whether or not compression is active.

In the absence of a solution to this problem at the django-compressor level, we can work around this by running CssAbsoluteFilter as part of the precompilation step, as described here: django-compressor/django-compressor#226 (comment). I propose to incorporate this workaround into django-libsass itself.

It doesn't matter if django-compressor subsequently runs CssAbsoluteFilter again, because CssAbsoluteFilter leaves existing absolute paths intact - however, it will add a cache-busting suffix to them, so ideally we should run a monkey-patched version CssAbsoluteFilter that skips this step, to avoid this happening twice.

libsass==0.19.4
Django==3.0.5
django-libsass==0.8
django-compressor==2.4

Noticed as small quirk in trying to import scss files

@import "materialize-src/sass/materialize";
// single quotes not working
// @import 'materialize-src/sass/materialize';

Exception information:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/pip/basecommand.py", line 122, in main
status = self.run(options, args)
File "/usr/local/lib/python2.7/site-packages/pip/commands/install.py", line 283, in run
requirement_set.install(install_options, global_options, root=options.root_path)
File "/usr/local/lib/python2.7/site-packages/pip/req.py", line 1435, in install
requirement.install(install_options, global_options, _args, *_kwargs)
File "/usr/local/lib/python2.7/site-packages/pip/req.py", line 706, in install
cwd=self.source_dir, filter_stdout=self._filter_install, show_stdout=False)
File "/usr/local/lib/python2.7/site-packages/pip/util.py", line 697, in call_subprocess
% (command_desc, proc.returncode, cwd))
InstallationError: Command /usr/local/bin/python2.7 -c "import setuptools, tokenize;file='/tmp/pip_build_root/libsass/setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().replace('\r\n', '\n'), file, 'exec'))" install --record /tmp/pip-sWz80n-record/install-record.txt --single-version-externally-managed --compile failed with error code 1 in /tmp/pip_build_root/libsass

This seems wrong: https://github.com/torchbox/django-libsass/blob/master/django_libsass.py#L19

This doesn't allow me to concatenate paths/use variables in conjunction with the static function, because double quotes end up in the middle of the string.

In django templates, users have to explicitly add wrapping quotes where they want them, for good reason: <img src="{% static "my_app/example.jpg" %}">.

I just learned that libsass is deprecated, and I was wondering if this package is going to migrate to another alternative?

Since version 1.6 django-compressor does not pass filename to sass/scss file but instead invokes it by passing source as a string. Because no filename is not passed libsass has no way of knowing where to search for scss includes.

libsass-python 0.10 introduced import callbacks, which allow us to handle @import lines through custom code. This means we could potentially support non-filesystem-based storage backends that don't directly expose a libsass-usable path.

Hi guys,
Thanks for great library.
Unfortunately can't use generated source map - paths to them are really crazy, sometimes buggy I think - for example "/static/all/" instead "static_all".

Please tell me if I need keep my scss files in CAHED/css subdirecotry?
[17/Jun/2016 07:25:39] "GET /static/CACHE/css/bootstrap/_variables.scss HTTP/1.1" 404 1819

css in path?
I have them in COMPRESS_ROOT of course. So, maby I need create symbolic link? Can't more easier? Please explain me and others how it works.

Is there any possibility not having to install libsass on the production server?
With ./manage compress I am able to convert all my scss files into css on the development server. Here they are stored below static/CACHE/css/... together with a manifest.json file, but I did not find out how to access these precompiled files on a production host without adding ('text/x-scss', 'django_libsass.SassCompiler') to COMPRESS_PRECOMPILERS.

Did you ever solve this problem?

I expected the following to compile the sass code and inline it in the rendered HTML:

{% compress css inline %}
    <link rel="stylesheet" type="text/x-scss" href="{% static "toolbar.scss" %}" />
{% endcompress %}

Instead, it simply links to the compiled file.

The inline method works fine for plain CSS files with django-compressor but it's not working for sass files.

Am I missing something or is this a bug in django-libsass?

Thanks for the good package.

Is it possible django-libsass support more parameter which libsass-python support?

such as source map, it may be very useful.

hi
goods day.
I set some variable, cause sass error.
Is only scss can be used?

error msg:

Error: Invalid CSS after "...ry-blue:#005d8d": expected 1 selector or at-rule, was "{}"
        on line 1:24 of static/theme.sass
        from line 1:1 of static/detail.sass
>> $p-primary-blue:#005d8d {}

theme.sass:

$p-primary-blue:#005d8d
$p-secondary-blue:#4ac0f0
$card-backgroud-gray: #eeeeee
$font-gray:#666666
$font-title-gray:#999999
$new-green:#00A08E

@mixin flex-center()
    display: flex
    align-items: center
    justify-content: center

setting.py:

COMPRESS_PRECOMPILERS = (
    ('text/x-sass', 'django_libsass.SassCompiler'),
)
COMPRESS_OFFLINE = True
LIBSASS_OUTPUT_STYLE = 'compressed'

detail.html

{% compress css %}
    <link type="text/x-sass" href="{% static 'detail.sass' %}" rel="stylesheet" media="screen">
{% endcompress %}

thank you

From my reading of the docs, I thought I could add the following to my settings,

STATICFILES_DIRS = (
    ('css/bootstrap', _Path(BASE_DIR, 'node_modules/bootstrap-sass/assets/stylesheets/bootstrap')),
    ('scss', _Path(BASE_DIR, 'django-site/django_app/static/scss')),
)

STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
    'compressor.finders.CompressorFinder',
)

Then, in my main scss file (django-site/django_app/static/scss/main.scss), use

// @import "../../../../node_modules/bootstrap-sass/assets/stylesheets/bootstrap/variables";
@import "css/bootstrap/variables";

However, if I do, I get a CompileError: File to import not found or unreadable: css/bootstrap/variables even though the commented out relative path works fine.