How can I compile Bootstrap 4 scss with python webassets? - python

I'm trying to simply compile Bootstrap 4 with python webassets and having zero success. For now I'm just trying to do this within the bootstrap/scss directory so path issues are less of a big deal. Within this directory I have added a main.scss file with one line:
#import "bootstrap.scss";
I have a script called test_scss.py that looks like this:
from webassets import Bundle, Environment
my_env = Environment(directory='.', url='/')
css = Bundle('main.scss', filters='scss', output='all.css')
my_env.register('css_all', css)
print(my_env['css_all'].urls())
When I run this command, I get an error trace like this:
Traceback (most recent call last):
File "./test_scss.py", line 11, in <module>
print(my_env['css_all'].urls())
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/bundle.py", line 806, in urls
urls.extend(bundle._urls(new_ctx, extra_filters, *args, **kwargs))
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/bundle.py", line 765, in _urls
*args, **kwargs)
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/bundle.py", line 619, in _build
force, disable_cache=disable_cache, extra_filters=extra_filters)
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/bundle.py", line 543, in _merge_and_apply
kwargs=item_data)
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/merge.py", line 276, in apply
return self._wrap_cache(key, func)
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/merge.py", line 218, in _wrap_cache
content = func().getvalue()
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/merge.py", line 251, in func
getattr(filter, type)(data, out, **kwargs_final)
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/filter/sass.py", line 196, in input
self._apply_sass(_in, out, os.path.dirname(source_path))
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/filter/sass.py", line 190, in _apply_sass
return self.subprocess(args, out, _in, cwd=child_cwd)
File "/Users/benlindsay/miniconda/lib/python3.6/site-packages/webassets/filter/__init__.py", line 527, in subprocess
proc.returncode, stdout, stderr))
webassets.exceptions.FilterError: scss: subprocess returned a non-success result code: 65, stdout=b'',
stderr=b'DEPRECATION WARNING: Importing from the current working directory will
not be automatic in future versions of Sass. To avoid future errors, you can add it
to your environment explicitly by setting `SASS_PATH=.`, by using the -I command
line option, or by changing your Sass configuration options.
Error: Invalid CSS after "...lor}: #{$value}": expected "{", was ";"
on line 4 of /Users/benlindsay/scratch/python/webassets/test-2/bootstrap/scss/_root.scss
from line 11 of /Users/benlindsay/scratch/python/webassets/test-2/bootstrap/scss/bootstrap.scss
from line 1 of standard input
Use --trace for backtrace.
If I follow the instructions and set environment variable SASS_PATH=., that gets rid of that part of the error message, but I still get the error
Error: Invalid CSS after "...lor}: #{$value}": expected "{", was ";"
on line 4 of /Users/benlindsay/scratch/python/webassets/test-2/bootstrap/scss/_root.scss
from line 11 of /Users/benlindsay/scratch/python/webassets/test-2/bootstrap/scss/bootstrap.scss
from line 1 of standard input
Use --trace for backtrace.
I don't know SCSS syntax well yet, but I'd bet a lot of money this is me doing something wrong and not an error in the Bootstrap SCSS. Any thoughts of what I'm doing wrong would be greatly appreciated.

Turns out it actually kind of was a problem on Bootstrap's end. See https://github.com/sass/sass/issues/2383, specifically the quote:
This is a bug in our implementation—the parser shouldn't crash—but those Bootstrap styles aren't valid for Sass 3.5 as written.
Anyway, I just needed to update to the latest version of Ruby Sass (which apparently the webassets module depends on) and that fixed it.

Related

Error when loading a custom model with spacy

I'm trying to load a custom model called 'ru2' into spacy (for npl processing).
it can be found there: https://github.com/buriy/spacy-ru
The problem is when I call the function
nlp = spacy.load('ru2')
doc = nlp(text)
I see the error
C:\ProgramData\Anaconda3\lib\importlib\_bootstrap.py:205: RuntimeWarning: spacy.tokens.span.Span size changed, may indicate binary incompatibility. Expected 72 from C header, got 80 from PyObject
return f(*args, **kwds)
Traceback (most recent call last):
File "C://.../nlp/src/ie/main.py", line 125, in <module>
main(examp_dict['Poroshenko'])
File "C://.../nlp/src/ie/main.py", line 92, in main
nlp = spacy.load('ru2')
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\__init__.py", line 27, in load
return util.load_model(name, **overrides)
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\util.py", line 133, in load_model
return load_model_from_path(Path(name), **overrides)
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\util.py", line 173, in load_model_from_path
return nlp.from_disk(model_path)
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\language.py", line 791, in from_disk
util.from_disk(path, deserializers, exclude)
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\util.py", line 630, in from_disk
reader(path / key)
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\language.py", line 781, in <lambda>
deserializers["tokenizer"] = lambda p: self.tokenizer.from_disk(p, exclude=["vocab"])
File "tokenizer.pyx", line 391, in spacy.tokenizer.Tokenizer.from_disk
File "tokenizer.pyx", line 432, in spacy.tokenizer.Tokenizer.from_bytes
File "C:\ProgramData\Anaconda3\lib\site-packages\spacy\util.py", line 606, in from_bytes
msg = srsly.msgpack_loads(bytes_data)
File "C:\ProgramData\Anaconda3\lib\site-packages\srsly\_msgpack_api.py", line 29, in msgpack_loads
msg = msgpack.loads(data, raw=False, use_list=use_list)
File "C:\ProgramData\Anaconda3\lib\site-packages\srsly\msgpack\__init__.py", line 60, in unpackb
return _unpackb(packed, **kwargs)
File "_unpacker.pyx", line 191, in srsly.msgpack._unpacker.unpackb
TypeError: unhashable type: 'list'
I was searching for similar questions in the Internet:
https://github.com/explosion/spaCy/issues/2715
https://spacy.io/usage#unhashable-list
But non of those solutions work for me.
I use
msgpack==0.5.6 (even downgraded as suggested in the link above)
spacy==2.1.4
Here is from https://spacy.io/usage#troubleshooting
If you’re training models, writing them to disk, and versioning them with git, you might encounter this error when trying to load them in a Windows environment. This happens because a default install of Git for Windows is configured to automatically convert Unix-style end-of-line characters (LF) to Windows-style ones (CRLF) during file checkout (and the reverse when committing). While that’s mostly fine for text files, a trained model written to disk has some binary files that should not go through this conversion. When they do, you get the error above. You can fix it by either changing your core.autocrlf setting to "false", or by committing a .gitattributes file] to your repository to tell git on which files or folders it shouldn’t do LF-to-CRLF conversion, with an entry like path/to/spacy/model/** -text. After you’ve done either of these, clone your repository again.
It might be because the version number of SpaCy used to generate your model is not the same as the version of SpaCy you have installed. (I don't know of course, just mentioning it in case it helps.)
Adding to the answer above, another quick fix would be to manually download the zip from the repository.

Py.test collection phase taking very long

I am really quite new to development in Python in general, let alone testing with pytest. My problem is that the pytest collection phase runs unusually slow. I am specifying the test directory which contains only a handful of files with only one file containing three tests. The collection takes pretty much a whole minute, after which the actual tests run in under a few seconds. I have looked at similar questions but couldn't find a solution. I don't think it matters (as py.test is slow even from the command line) but I am using the pycharm IDE. The OS is Ubuntu.
This may be relevant: If I terminate the process after a few seconds I usually end up with a stacktrace ending as follows:
<A FEW LINES OMITTED...>
File "/usr/local/lib/python2.7/dist-packages/_pytest/core.py", line 413, in __call__
return self._docall(methods, kwargs)
File "/usr/local/lib/python2.7/dist-packages/_pytest/core.py", line 424, in _docall
res = mc.execute()
File "/usr/local/lib/python2.7/dist-packages/_pytest/core.py", line 315, in execute
res = method(**kwargs)
File "/usr/local/lib/python2.7/dist-packages/_pytest/helpconfig.py", line 27, in pytest_cmdline_parse
config = __multicall__.execute()
File "/usr/local/lib/python2.7/dist-packages/_pytest/core.py", line 315, in execute
res = method(**kwargs)
File "/usr/local/lib/python2.7/dist-packages/_pytest/config.py", line 636, in pytest_cmdline_parse
self.parse(args)
File "/usr/local/lib/python2.7/dist-packages/_pytest/config.py", line 747, in parse
self._preparse(args)
File "/usr/local/lib/python2.7/dist-packages/_pytest/config.py", line 709, in _preparse
self._initini(args)
File "/usr/local/lib/python2.7/dist-packages/_pytest/config.py", line 704, in _initini
self.inicfg = getcfg(args, ["pytest.ini", "tox.ini", "setup.cfg"])
File "/usr/local/lib/python2.7/dist-packages/_pytest/config.py", line 861, in getcfg
if exists(p):
File "/usr/local/lib/python2.7/dist-packages/_pytest/config.py", line 848, in exists
return path.check()
File "/usr/local/lib/python2.7/dist-packages/py/_path/local.py", line 352, in check
return exists(self.strpath)
File "/usr/lib/python2.7/genericpath.py", line 18, in exists
os.stat(path)
KeyboardInterrupt
Or sometimes...
<STACK TRACE...>
File "/usr/local/lib/python2.7/dist-packages/py/_iniconfig.py", line 50, in __init__
f = open(self.path)
KeyboardInterrupt
Maybe one of the two last calls before the KeyboardInterrupt is very slow?
Please do ask for more detail should you require it!
Cheers!
Add PYTHONDONTWRITEBYTECODE=1 to your environment variables!
Windows Batch: set PYTHONDONTWRITEBYTECODE=1
Unix: export PYTHONDONTWRITEBYTECODE=1
subprocess.run: Add keyword env={'PYTHONDONTWRITEBYTECODE': '1'}
Note that the first two options are only valid for your current terminal session.
Here is how I found this out: pytest was being unusably slow from the command line, but working fine from within PyCharm. Copying the PyCharm command into cmd.exe (executes a small helper script) also was unusuably slow. Thus I printed out the environ variables at os.environ and tried it with that -- and it was fast! Then I eliminated each one-by-one.
I had the same problem. My fix was to set the Working directory setting in the Run/Debug Configuration to the folder where manage.py is located.
My solution was based off of this answer, where I did pytest dir/to/tests and it skipped the collection step entirely.

fexpect breaks fabric scripts

I hot upon an requirement where I needed to automatically answer the prompt on remote machine and then I found fexpect after reading different stackoverflow questions. But the moment I include fexpect in my script it breaks the whole script!
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/fabric/main.py", line 743, in main
*args, **kwargs
File "/usr/local/lib/python2.7/dist-packages/fabric/tasks.py", line 368, in execute
multiprocessing
File "/usr/local/lib/python2.7/dist-packages/fabric/tasks.py", line 264, in _execute
return task.run(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/fabric/tasks.py", line 171, in run
return self.wrapped(*args, **kwargs)
File "/etc/puppet/fabfile.py", line 165, in edit_sudoers
run('echo "Current Permission of the file /etc/sudoers - "`stat -c "%a %n" /etc/sudoers`')
File "/usr/local/lib/python2.7/dist-packages/ilogue/fexpect/api.py", line 15, in run
wrappedCmd = wrapExpectations(cmd)
File "/usr/local/lib/python2.7/dist-packages/ilogue/fexpect/internals.py", line 15, in wrapExpectations
script = createScript(cmd)
File "/usr/local/lib/python2.7/dist-packages/ilogue/fexpect/internals.py", line 39, in createScript
for e in fabric.state.env.expectations:
File "/usr/local/lib/python2.7/dist-packages/fabric/utils.py", line 184, in __getattr__
raise AttributeError(key)
AttributeError: expectations
The moment i write
from ilogue.fexpect import expect, expecting, run fabric stops working with the above error message.
I asked in fabric irc as well but I got to know that this might be because of some version related issues. Has anyone else encountered this error before?
fexpect==0.2.post7
Fabric==1.8.0
Just import fexpect's run as erun and its sudo as esudo.
When you use the fexpect run or sudo functions, you must wrap those calls in a with expecting(prompts): context. This is a known issue in fexpect, although there is a pull request, so it might be fixed by the time posterity reads this.
One solution is to import fexpect's run function with a different name, e.g. erun, and use it only when you need the automatic prompt handling functionality:
from fabric.api import run
from ilogue.fexpect import expect, expecting, run as erun
run(a_cmd) # Native Fabric run - should work fine
prompts = [...]
with expecting(prompts):
erun(a_prompting_cmd) # fexpect run - should with fine inside expecting context
Another thing that isn't explicitly stated in the fexpect documentation is that the pexpect package needs to be installed on the target system.
Yet another fexpect gotcha is that the prompt strings are regular expressions -- the fexpect sample code is misleading about this.

WebPy: AttributeError No template named index

Recently I have been trying to learn WebPy and when attempting to use a template in the tutorial (http://webpy.org/docs/0.3/tutorial) I come across this error when trying to access the page.
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/application.py", line 239, in process
return self.handle()
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/application.py", line 230, in handle
return self._delegate(fn, self.fvars, args)
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/application.py", line 420, in _delegate
return handle_class(cls)
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/application.py", line 396, in handle_class
return tocall(*args)
File "/Users/clement/Desktop/#Minecraft/index2.py", line 14, in GET
return render.index(name)
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/template.py", line 1017, in __getattr__
t = self._template(name)
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/template.py", line 1014, in _template
return self._load_template(name)
File "/Library/Python/2.7/site-packages/web.py-0.37-py2.7.egg/web/template.py", line 1001, in _load_template
raise AttributeError, "No template named " + name
AttributeError: No template named index
I've looked at this Question on SOF but I couldn't get it to work in my situation. I've spent about 4 hours trying to figure this out and have attempted to rework the way I launch the service which is usually done by:
Macintosh-2:~ clement$ python /Users/clement/Desktop/\#Minecraft/index.py
Thanks!
I believe I have found the answer.
To Solve:
CD into the directory containing main.py (or in my case index.py)
Make sure your HTML files are in a directory in the directory you cd'd into called 'templates'
run via: python [full path to main.py]
Hopes this helps people with similar issues :)
(Note: Running OS X 10.8.1)

GAE Python dev server crashes intermittently after upgrade to 2.7

I recently upgraded my GAE Python app to Python 2.7. Since then, I periodically get the following error with the dev server and the dev server serves up a blank page:
Traceback (most recent call last):
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py", line 168, in Handle
handler = _config_handle.add_wsgi_middleware(self._LoadHandler())
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py", line 206, in _LoadHandler
handler = __import__(path[0])
[...]
File "/Users/joneill/OpenSTV/OpenSTV/trunk/OpaVote-HR/main.py", line 2, in <module>
import views
[...]
File "/Users/joneill/OpenSTV/OpenSTV/trunk/OpaVote-HR/views.py", line 3, in <module>
from pytz.gae import pytz
[...]
File "/Users/joneill/OpenSTV/OpenSTV/trunk/OpaVote-HR/pytz/__init__.py", line 34, in <module>
from pkg_resources import resource_stream
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 662, in Decorate
return func(self, *args, **kwargs)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1818, in load_module
return self.FindAndLoadModule(submodule, fullname, search_path)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 662, in Decorate
return func(self, *args, **kwargs)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1690, in FindAndLoadModule
description)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 662, in Decorate
return func(self, *args, **kwargs)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1615, in LoadModuleRestricted
return source_file.load_module(submodule_fullname)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/dist/py_zipimport.py", line 246, in load_module
submodname, is_package, fullpath, source = self._get_source(fullmodname)
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/dist/py_zipimport.py", line 207, in _get_source
source = self.zipfile.read(relpath.replace(os.sep, '/'))
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 867, in read
return self.open(name, "r", pwd).read()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/zipfile.py", line 882, in open
zef_file = open(self.filename, 'rb')
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 578, in __init__
raise IOError(errno.EACCES, 'file not accessible', filename)
IOError: [Errno 13] file not accessible: '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg'
INFO 2012-01-21 20:50:44,222 dev_appserver.py:2832] "POST /manage HTTP/1.1" 500 -
Some notes:
This doesn't happen on the production server.
On the dev server, my app will work for a few minutes and then this error happens.
If I stop and restart my app on the dev server, it will work again for a few minutes.
I am using the latest version of gae-pytz and you can see that it fails in an import there.
The [...] that I removed are similar to the stuff you see near the end.
I don't know why setuptools is being invoked at the end.
I'm using a Mac with Lion.
I can use the dev server, but it is really annoying to stop and restart every few minutes. Any ideas how to fix this?
The actual problem from the stack trace, is your code is trying to import setup tools from site-packages, which the dev server won't do.
'/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg'
You will need to include setuptools in you application code base. The fact that it works sometimes, suggests that you code paths through various modules vary, and maybe (depending on what your tesing in dev) different import orders mean setup tools has been imported somewhere else, or is only required at certain points in your code.
Have a look at line 4th line of the stack trace where pytz is imported, the next line is from pkg_resources import resource_stream thats whats triggering the rest of the import issue. I use a fake truncated pkg_resources at the root of my project, that doesn't end up trying to import stuff from setup tools. You can run the dev server in debug import mode which will tell you a lot more
Here is a fake pkg_resources.
"""Package resource API
--------------------
A resource is a logical file contained within a package, or a logical
subdirectory thereof. The package resource API expects resource names
to have their path parts separated with ``/``, *not* whatever the local
path separator is. Do not use os.path operations to manipulate resource
names being passed into the API.
The package resource API is designed to work with normal filesystem packages,
.egg files, and unpacked .egg files. It can also work in a limited way with
.zip files and with custom PEP 302 loaders that support the ``get_data()``
method.
"""
import sys, os, zipimport, time, re, imp, new
try:
frozenset
except NameError:
from sets import ImmutableSet as frozenset
from os import utime #, rename, unlink # capture these to bypass sandboxing
from os import open as os_open
There are probably other/better ways of doing this, but it works for me.
Oh, I would also suggest you use http://code.google.com/p/gae-pytz/ instead of pytz.
Cheers
An alternative answer to the above that I prefer.
The __init__.py file for pytz contains the following lines:
#try:
# from pkg_resources import resource_stream
#except ImportError:
resource_stream = None
I commented out the first three lines and that fixed the problem.
The problem is a bug in the App Engine dev server with Python 2.7. The solution is here:
File not accesible error (setuptools) in logs

Categories