The problem
Foundation 5 was released last week, that's great, but the new version requires to use bower for using F5 with SASS and the official documentation seems to be a bit incomplete and immature.
I'm trying to create a project using the steps proposed by the docs:
[sudo] npm install -g bower
and then
gem install foundation
No problems here. The problem is when creating a Compass project:
foundation new MY_PROJECT
cd MY_PROJECT
compass compile
After Compass compilation, I get the following error:
directory stylesheets/
error scss/app.scss (Line 1: File to import not found or unreadable: settings.
Load paths:
/home/cartucho/MY_PROJECT/scss
/var/lib/gems/1.9.1/gems/compass-0.12.2/frameworks/blueprint/stylesheets
/var/lib/gems/1.9.1/gems/compass-0.12.2/frameworks/compass/stylesheets
/home/cartucho/MY_PROJECT/bower_components/foundation/scss
Compass::SpriteImporter)
create stylesheets/app.css
Compass config file (config.rb):
# Require any additional compass plugins here.
add_import_path "bower_components/foundation/scss"
# Set this to the root of your project when deployed:
http_path = "/"
css_dir = "stylesheets"
sass_dir = "scss"
images_dir = "images"
javascripts_dir = "javascripts"
The SASS file (app.sass):
#import "settings";
#import "foundation";
...
The problem seems to be in config.rb:
add_import_path "bower_components/foundation/scss"
because Compass fail trying to import the files settings and foundation but I don't know how to fix it. Any help will be highly appreciated.
Thanks.
You need to change the line foundation new MY_PROJECT by replacing MY_PROJECT with the folder you want to install the project on. After that, confirm that these folders exist on the directory you specified above - "bower_components/foundation/scss"
When starting a project run compass init and then compass watch (in Terminal) to watch for changes on the .sass files.
Personally, I don't go that route and use http://koala-app.com/ to convert or "compile" my Sass. It's FREE and awesome.
This is SASS were talking about. Please correct me if i'm wrong but you don't need the underscore when importing an "include" file. I create separate sass files for my variables and my mix-ins. They are prefixed with and underscore which signifies an "include" file. SASS recognizes #import "variables"; as #import "_variables.scss". So to be clear when it is an include file just the name of the sass file is need not the _ or the scss extension.
I have never put an underscore before any include file that I have named _filename.scss.
There is probably another issue going on. Possibly with the install and the paths for bower. For those who did add the underscore in the past and it worked...well you just bypass what could become a deeper issue down the road. You need to check your install.
In your app.sass file change the following line
#import "settings";
To
#import "_settings";
Explaination
When you run compass watch you got the error
error scss/app.scss (Line 1: File to import not found or unreadable: settings.
This just means it can't find the settings file being imported. By adding the underscore to the settings file you have specified the correct file path. If you receive any other errors like this, make sure the file path is correct.
I think I had the same error; finally I found in the _settings.scss
You need to underscore before the importing the functions
Before:
// Uncomment to use rem-calc() in your settings
#import "foundation/functions";
After:
// Uncomment to use rem-calc() in your settings
#import "foundation/_functions";
Also you would need to import the settings same way.
In my example I made style.scss and import all the SCSS inside :
#import "foundation/_settings", "_normalize", "_foundation";
I encountered this same issue, but for me the solution was to change the import of settings in app.scss from:
#import "settings";
To:
#import "foundation/_settings";
Once you've done that, run compass watch again.
You can install Grunt into your project which uses compass's watch function and then some other clever stuff to compile your sass and livereload it in the browser! Here's a great tutorial on how to get it up and running! (it's as simple as creating two new files in the root of your project and then running a few commands from your command line! I seriously advise it!)
http://moduscreate.com/get-up-and-running-with-grunt-js/
I had the same problem.
For Ubuntu 14.04 users make sure nodejs and Bower are working properly.
You can follow these instructions here http://www.codediesel.com/javascript/installing-bower-on-ubuntu-14-04-lts/comment-page-1/#comment-63283
I am trying to link my Sphinx documentation with ReadtheDocs. I can build the documentation locally but when I try to have ReadtheDocs automatically generate the documentation I get the following error:
Sphinx Standard Error
Making output directory...
Exception occurred:
File "/var/build/user_builds/mousedb/checkouts/latest/Docs/source/conf.py", line 25, in <module>
from mousedb import settings
ImportError: No module named mousedb
The full traceback has been saved in /tmp/sphinx-err-n_8fkR.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
My project name is mousedb. I don't understand why I get this import error in the auto-build but not locally.
Update
Based on the comments I think that this is an issue for importing my settings file into a sibling Docs directory. Rather than doing an absolute import (as I had been doing) I should be doing a relative import based on the location of settings.py and conf.py.
I want to import my settings file into my conf.py with the following directory structure:
-mousedb
--settings.py
-Docs
--source
---conf.py
--build
You originally talked about a "local absolute path to my code" and now about setting up relative paths to your code. This probably means you're not using a setup.py file and also not a virtualenv.
In the same directory as Docs/ and mousedb/, add a setup.py:
from setuptools import setup
setup(name='mousedb',
version='0.1',
description="My sample package",
long_description="",
author='TODO',
author_email='todo#example.org',
license='TODO',
packages=['mousedb'],
zip_safe=False,
install_requires=[
'Django',
# 'Sphinx',
# ^^^ Not sure if this is needed on readthedocs.org
# 'something else?',
],
)
After committing/pushing/whatever this file, you can go to your readthedocs settings for your project. Enable the "use virtualenv" setting. This will "nstall your project inside a virtualenv using setup.py install".
The end result is that everything python-related that readthedocs does will have your project in it's sys.path.
The probable cause of your problems is that you run sphinx from within your "root" directory on your local system, where python magically finds the mousedb/ package in your current directory. But readthedocs apparently runs it from within the Docs/ directory and thus cannot find mousedb.
My overall goal is to get django running on a server for which I don't have root access. I have convinced the admin to install mod_fcgid on the main apache server, but that is basically all I can do from the root side.
After a lot of struggling, my current setup is to create a virtualenv, install django, flup and MySQLdb-python in the virtualenv and make a "mysite.fcgi" script in a web accessible directory for which the .htaccess file uses fastcgid for .fcgi files. This all works and when I use a browser to load mysite.fcgi, then my django project is successfully reached - I know this because I get a django error page (instead of the countless "premature end of script headers" 500 pages I was getting while trying to figure out all the paths).
So, the django error page I am getting says:
ImproperlyConfigured at /
Error loading MySQLdb module: libmysqlclient.so.18: cannot open shared object file: No such file or directory
However, I know that everything basically works, since I can do "python manage.py runserver" as long as I add this line to my bash shell before running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/alternate_versions/mysql-5.5.11/lib
Thus, I tried adding this to my .htaccess file:
SetEnv LD_LIBRARY_PATH /opt/alternate_versions/mysql-5.5.11/lib
But, that does not affect my django error message (other than showing the correctly set environment variable in the bottom of the django debug screen). I don't know why this doesn't work.
This leads me back to the MySQLdb-python package. I built that by downloading the source and running "python setup.py build" and "python setup.py install" from within my virtualenv. However, THIS IS MAYBE THE KEY PROBLEM: I need to use a mysql installation which is not the system default! The default installation does not have the source nor the mysql_config command. The alternate install is newer and has the source/devel version, which is required for mysql-python. So, in the site.cfg file for MySQLdb-python I had to specify the mysql_config variable to point at the alternate mysql installation:
mysql_config = /opt/alternate_versions/mysql-5.5.11-src/scripts/mysql_config
When I run mysql_config using the --libs option, it is (correctly?) pointing to the directory in which the libmysqlclient.so.18 file lives:
-L/var/alternate_versions/mysql-5.5.11/lib -lmysqlclient -lpthread -lz -lm -lrt -ldl
Ideas for moving forward:
Is there an alternate way to build the MySQLdb libraries? I tried the various options in the site.cfg file (static=True, embedded=True), but this doesn't work either. I didn't try all combinations of those options, since I don't really know what they are doing.
Can I manually add the path to the MySQLdb library? I think it is in an egg file, which I have no idea how to modify.
If MySQLdb was installed as root, would that make a difference? I want to be confident in this option before asking the admin to try it. We still have the problem of needing the alternate mysql installation.
Is there a different way to specify the LD_LIBRARY_PATH for apache?
Thanks for any suggestions.
Ok, I solved my problem by cheating. I downloaded a rpm for my version of Suse, got out the files using this command:
rpm2cpio python-mysql-1.2.2-1.79.x86_64.rpm | cpio -idmv
Then, I copied all the files to my virtualenv directory:
cp -pir ./usr/lib64/python2.6/site-packages/* ../virt/lib/python2.6/site-packages/
And, it worked!
recently I want to learn django in eclipse, but when I set up eclipse environment , I get a problem...
the django project cannot find my templates folder in eclipse
in the setting.py:
import os
TEMPLATE_DIRS = (
os.path.abspath('templates'),
)
the templates folder:
D:\django_workspace\eagle\eagle\templates
I run 'manage.py shell' and get:
>>> os.path.abspath('templates')
'D:\\django_workspace\\eagle\\eagle\\templates'
but, in eclipse I run the command:
>>>os.path.abspath('templates')
'D:\\Program Files\\eclipse\\templates'
it seems that the os root path is set to be 'D:\Program Files\eclipse' where I install the eclispe
how can I solve this problem ??
thx
The way you're doing it, you're getting the absolute path from a relative path based on the current working directory, so, your code will fail depending on your current directory...
Better would be actually calculating the path based on __file__ from your module (something as os.path.join(os.path.dirname(__file__), 'templates') -- not really sure where your settings file is relative to your templates, so, in your environment it may be a bit different.
I am attempting to put together a simple c++ test project that uses an embedded python 3.2 interpreter. The project builds fine but Py_Initialize raises a fatal error:
Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding
Minimal code:
#include <Python.h>
int main (int, char**)
{
Py_Initialize ();
Py_Finalize ();
return 0;
}
The OS is 32bit Vista.
The python version used is a python 3.2 debug build, built from sources using VC++ 10.
The python_d.exe file from the same build runs without any problems.
Could someone explain the problem and how to fix it? My own google-fu fails me.
EDIT 1
After going through the python source code I've found that, as the error says, no codec search functions have been registered. Both codec_register and PyCodec_Register are as they should be. It's just that nowhere in the code are any of these functions called.
I don't really know what this means as I still have no idea when and from where these functions should have been called. The code that raises the error is entirely missing from the source of my other python build (3.1.3).
EDIT 2
Answered my own question below.
Check the PYTHONPATH and PYTHONHOME environment variables and make sure they don't point to Python 2.x.
http://bugs.python.org/issue11288
Parts of this have been mentioned before, but in a nutshell this is what worked for my environment where I have multiple Python installs and my global OS environment set-up to point to a different install than the one I attempt to work with when encountering the problem.
Make sure your (local or global) environment is fully set-up to point to the install you aim to work with, e.g. you have two (or more) installs of, let's say a python27 and python33 (sorry these are windows paths but the following should be valid for equivalent UNIX-style paths just as well, please let me know about anything I'm missing here (probably the DLLs path might differ)):
C:\python27_x86
C:\python33_x64
Now, if you intend to work with your python33 install but your global environment is pointing to python27, make sure you update your environment as such (while PATH and PYTHONHOME may be optional (e.g. if you temporarily work in a local shell)):
PATH="C:\python33_x64;%PATH%"
PYTHONPATH="C:\python33_x64\DLLs;C:\python33_x64\Lib;C:\python33_x64\Lib\site-packages"
PYTHONHOME=C:\python33_x64
Note, that you might need/want to append any other library paths to your PYTHONPATH if required by your development environment, but having your DLLs, Lib and site-packages properly set-up is of prime importance.
Hope this helps.
The core reason is quite simple: Python does not find its modules directory, so it can of course not load encodings, too
Python doc on embedding says "Py_Initialize() calculates the module search path based upon its best guess" ... "In particular, it looks for a directory named lib/pythonX.Y"
Yet, if the modules are installed in (just) lib - relative to the python binary - above guess is wrong.
Although docs says that PYTHONHOME and PYTHONPATH are regarded, we observed that this was not the case; their actual presence or content was completely irrelevant.
The only thing that had an effect was a call to Py_SetPath() with e.g. [path-to]\lib as argument before Py_Initialize().
Sure this is only an option for an embedding scenario where one has direct access and control over the code; with a ready-made solution, special steps may be necessary to solve the issue.
Ran into the same thing trying to install brew's python3 under Mac OS! The issue here is that in Mac OS, homebrew puts the "real" python a whole layer deeper than you think. You would think from the homebrew output that
$ echo $PYTHONHOME
/usr/local/Cellar/python3/3.6.2/
$ echo $PYTHONPATH
/usr/local/Cellar/python3/3.6.2/bin
would be correct, but invoking $PYTHONPATH/python3 immediately crashes with the abort 6 "can't find encodings." This is because although that $PYTHONHOME looks like a complete installation, having a bin, lib etc, it is NOT the actual Python, which is in a Mac OS "Framework". Do this:
PYTHONHOME=/usr/local/Cellar/python3/3.x.y/Frameworks/Python.framework/Versions/3.x
PYTHONPATH=$PYTHONHOME/bin
(substituting version numbers as appropriate) and it will work fine.
From python3k, the startup need the encodings module, which can be found in PYTHONHOME\Lib directory.
In fact, the API Py_Initialize () do the init and import the encodings module.
Make sure PYTHONHOME\Lib is in sys.path and check the encodings module is there.
I had this issue with python 3.5, anaconda 3, windows 7 32 bit. I solved it by moving my pythonX.lib and pythonX.dll files into my working directory and calling
Py_SetPythonHome(L"C:\\Path\\To\\My\\Python\\Installation");
before initialize so that it could find the headers that it needed, where my path was to "...\Anaconda3\". The extra step of calling Py_SetPythonHome was required for me or else I'd end up getting other strange errors where python import files.
I just ran into the exact same problem (same Python version, OS, code, etc).
You just have to copy Python's Lib/ directory in your program's working directory ( on VC it's the directory where the .vcproj is )
There appears to be something going wrong with the release build either failing to include the appropriate codecs or else misidentifying the codec to use for system APIs. Since the python_d executable is working, what does that return for os.getfsencoding()? (Use the C API to call that between your Initialize/Finalize calls)
I had the same issue and found this question. However from the answers here I was not able to solve my problem. I started debugging the cpython code and thought that I might be discovered a bug. Therefore I opened a issue on the python issue tracker.
My mistake was that I did not understand that Py_SetPath clears all inferred paths.
So one needs to set all paths when calling this function.
Link to the issue conversation
For completion I also copied the most important part of the conversation below.
My original issue text
I compiled the source of CPython 3.7.3 myself on Windows with Visual Studio 2017 together with some packages like e.g numpy. When I start the Python Interpreter I am able to import and use numpy. However when I am running the same script via the C-API I get an ModuleNotFoundError.
So the first thing I did, was to check if numpy is in my site-packages directory and indeed there is a folder named numpy-1.16.2-py3.7-win-amd64.egg. (Makes sense because the python interpreter can find numpy)
The next thing I did was to get some information about the sys.path variable created when running the script via the C-API.
#### sys.path content ####
C:\Work\build\product\python37.zip
C:\Work\build\product\DLLs
C:\Work\build\product\lib
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\EXTENSIONS\TESTPLATFORM
C:\Users\rvq\AppData\Roaming\Python\Python37\site-packages
Examining the content of sys.path I noticed two things.
C:\Work\build\product\python37.zip has the correct path 'C:\Work\build\product\'. There was just no zip file. All my files and directory were unpacked. So I zipped the files to an archive named python37.zip and this resolved the import error.
C:\Users\rvq\AppData\Roaming\Python\Python37\site-packages is wrong it should be C:\Work\build\product\Lib\site-packages but I dont know how this wrong path is created.
The next thing I tried was to use Py_SetPath(L"C:/Work/build/product/Lib/site-packages") before calling Py_Initialize(). This led to
Fatal Python Error 'unable to load the file system encoding'
ModuleNotFoundError: No module named 'encodings'
I created a minimal c++ project with exact these two calls and started to debug Cpython.
int main()
{
Py_SetPath(L"C:/Work/build/product/Lib/site-packages");
Py_Initialize();
}
I tracked the call of Py_Initialize() down to the call of
static int
zipimport_zipimporter___init___impl(ZipImporter *self, PyObject *path)
inside of zipimport.c
The comment above this function states the following:
Create a new zipimporter instance. 'archivepath' must be a path-like
object to a zipfile, or to a specific path inside a zipfile. For
example, it can be '/tmp/myimport.zip', or
'/tmp/myimport.zip/mydirectory', if mydirectory is a valid directory
inside the archive. 'ZipImportError' is raised if 'archivepath'
doesn't point to a valid Zip archive. The 'archive' attribute of the
zipimporter object contains the name of the zipfile targeted.
So for me it seems that the C-API expects the path set with Py_SetPath to be a path to a zipfile. Is this expected behaviour or is it a bug?
If it is not a bug is there a way to changes this so that it can also detect directories?
PS: The ModuleNotFoundError did not occur for me when using Python 3.5.2+, which was the version I used in my project before. I also checked if I had set any PYTHONHOME or PYTHONPATH environment variables but I did not see one of them on my system.
Answer
This is probably a documentation failure more than anything else. We're in the middle of redesigning initialization though, so it's good timing to contribute this feedback.
The short answer is that you need to make sure Python can find the Lib/encodings directory, typically by putting the standard library in sys.path. Py_SetPath clears all inferred paths, so you need to specify all the places Python should look. (The rules for where Python looks automatically are complicated and vary by platform, which is something I'm keen to fix.)
Paths that don't exist are okay, and that's the zip file. You can choose to put the stdlib into a zip, and it will be found automatically if you name it the default path, but you can also leave it unzipped and reference the directory.
A full walk through on embedding is more than I'm prepared to type on my phone. Hopefully that's enough to get you going for now.
I had the problem and was tinkering with different solutions mentioned here. Since I was running my project from Visual Studio, apparently, I needed to set the environment path inside Visual Studio and not the system path.
Adding a simple PYTHONHOME=PATH\TO\PYTHON\DIR in the project solution\properties\environment solved the problem.
For me this happened when I updated Python 64 bit from 3.6.4 to 3.6.5. It threw some error like "unable to extract python.dll. Do you have permissions."
Pycharm also failed to load interpreter, even though I reloaded it in settings. Running python command gave same error, with and without administrator mode.
Reason
There was error in installation of Python, include folder in python installation directory C:\Users\USERNAME\AppData\Local\Programs\Python\Python36 was missing
Reinstalling Python also dint solve the issue.(Not removal and install)
Solution
Uninstall Python and Install of Python again.
Because running installer was just extracting same files excluding include folder
In my cases, for windows, if you have multiple python versions installed, if PYTHONPATH is pointing to one version the other ones didn't work. I found that if you just remove PYTHONPATH, they all work fine
For those working in Visual Studio simply add the include, Lib and libs directories to the Include Directories and Library Directories under
Projects Properties -> Configuration Properties > VC++ Directories :
For example I have Anaconda3 on my system and working with Visual Studio 2015 This is how the settings looks like (note the Include and Library directories) :
Edit:
As also pointed out by bossi setting PYTHONPATH in your user Environment Variables section seems necessary.
a sample input can be like this (in my case):
C:\Users\Master\Anaconda3\Lib;C:\Users\Master\Anaconda3\libs;C:\Users\Master\Anaconda3\Lib\site-packages;C:\Users\Master\Anaconda3\DLLs
is necessary it seems.
Also, you need to restart Visual Studio after you set up the PYTHONPATH in your user Environment Variables for the changes to take effect.
Also note that :
Make sure the PYTHONHOME environment variable is set to the Python
interpreter you want to use. The C++ projects in Visual Studio rely on
this variable to locate files such as python.h, which are used when
creating a Python extension.
So, for some reason the python dll fails to locate the encodings module. The python.exe executable apparently finds it because it has the expected relative path. Modifying the search path works.
The reason for all of this? Don't know but at least it works. I highly suspect a typo on my part somewhere, that's usually the reason for odd bugs it seems.