I'm just getting started with twisted.web, and I'm having trouble importing a Python module into a .rpy script.
in C:\py\twisted\mysite.py, I have this:
from twisted.web.resource import Resource
from twisted.web import server
class MySite(Resource):
def render_GET(self, request):
request.write("<!DOCTYPE html>")
request.write("<html><head>")
request.write("<title>Twisted Driven Site</title>")
request.write("</head><body>")
request.write("<h1>Twisted Driven Website</h1>")
request.write("<p>Prepath: <pre>{0}</pre></p>".format(request.prepath))
request.write("</body></html>")
request.finish()
return server.NOT_DONE_YET
and in C:\py\twisted\index.rpy, I have this:
import mysite
reload(mysite)
resource = mysite.MySite()
I ran twistd -n web --port 8888 --path C:\py\twisted in command prompt and the server started successfully. But when I requested localhost:8888 I got a (huge) stack trace originating from an ImportError:
<type 'exceptions.ImportError'>: No module named mysite
I can import the module from the interpreter, and if i just execute index.rpy as a python script, I don't get the import error. The documentation on this subject is a bit vague, it just says "However, it is often a better idea to define Resource subclasses in Python modules. In order for changes in modules to be visible, you must either restart the Python process, or reload the module:" (from here).
Does anyone know the proper way to do this?
Short answer: you need to set PYTHONPATH to include C:\py\twisted.
Long answer...
An rpy script is basically just some Python code, like any other Python code. So an import in a rpy script works just like an import in any other Python code. For the most common case, this means that the directories in sys.path are visited one by one, in order, and if a .py file matching the imported name is found, that file is used to define the module.
sys.path is mostly populated from a static definition including things like C:\Python26\Lib\ and from the PYTHONPATH environment variable. However, there's one extra thing worth knowing about. When you run "python", the current working directory is added to the front of sys.path. When you run "python C:\foo\bar\baz.py", C:\foo\bar\' is added to the front ofsys.path. But when you run "twistd ...", nothing useful is added tosys.path`.
This last behavior probably explains why your tests work if you run the rpy script directly, or if you run python and try to import the module interactively, but fail when you use twistd. Adding C:\py\twisted to the PYTHONPATH environment variable should make the module importable when the rpy script is run from the server you start with twistd.
Related
I am attempting to download a code from github which contains the library "ee" - Google Earth Engine. GitBash is giving me an error:
ModuleNotFoundError: No module named 'fcntl'
fcntl is a module within the library Google Earth Engine. I have Windows and it seems Linux is required. I was directed to add the module (fcntl) to the PYTHONPATH. Any other suggestions for this error would be helpful as well! The code I intend to add in PYTHONPATH is below.
def fcntl(fd, op, arg=0):
return 0
def ioctl(fd, op, arg=0, mutable_flag=True):
if mutable_flag:
return 0
else:
return ""
def flock(fd, op):
return
def lockf(fd, operation, length=0, start=0, whence=0):
return
First, this is probably not going to work for you.
You can't turn Windows to Linux just by adding modules to your Python library. The reason you don't have the fcntl module on your path is that fcntl isn't included on Windows. And the reason it isn't included on Windows is that the Windows OS doesn't support the syscalls that module wraps, or anything close enough to reasonably emulate those syscalls.
If you have code that requires fcntl, that code cannot run on Windows (unless you do some significant work to port it to not require fcntl in the first place).
If you have code that doesn't require fcntl but uses it anyway, or if you just need something for temporary development purposes so you can catch and fix file sharing errors while porting the code to not require fcntl, then you can use msoliman's dummy code, which I'll explain how to do below. But you seem to be expecting it to do magic, and it won't do that.
You may not be sure. Maybe you're using code that uses other code that uses other code that uses fcntl in some scenarios but not others, it may not actually need fcntl to do any of the things you're actually trying to do with it.
If you want to test that, you can take msoliman's dummy code, and change each function body to this:
raise RuntimeError('Oops, using fcntl!')
Then run the program and see if it fails with that error. If not, you don't actually need fcntl after all. (Or at least you don't need it for any of the things you tested—it's always possible that some other thing you need to do with the app that you didn't think to test will need it.)
If your code actually needs fcntl, and you don't want to/can't port that code to Windows code that uses Win32 API calls (or a cross-platform library like portalocker), then what you probably need to do is install Linux and run the program there.
There are multiple ways to run Linux on top of Windows, rather than instead of Windows. For example, you could install Docker for Windows and then build a linux docker container with the app. Or you could use VMWare Player to, in effect, run a Linux image as an application under Windows, and then do your work inside that image. And so on.
Finally, msoliman's "Place this module in your PYTHONPATH" is a little misleading.
What you actually need to do is get it into your sys.path. PYTHONPATH is just one way of doing that, and probably not the one you want here.
The options are:
Just put it in the same directory as your script. As the docs say, "As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter."
Put it in your user or system site packages, or some other directory that's already on your default sys.path. You can import sys; print(sys.path) to get a list of these directories. If you see something inside your home directory, that's a good place to put it; if not, look for something with site-packages in the name.
Put it in some other directory somewhere else, and set the PYTHONPATH environment variable to be the full path to directory. You can set an environment variable in the Windows cmd command prompt by writing SET PYTHONPATH C:\Path\To\Directory. This will only persist as long as the current command prompt window. If you want to set it permanently, there's a setting somewhere in Control Panel (it changes with each Windows version; Super User should have good up-to-date answers for each version) where you can set System and User environment variables. Any User environment variable will take effect in every new command prompt window you open from now on.
I'm sorry for this question I am not yet an expert to both django and meteorjs. I am trying to use this django-ddp technology but I am a little stuck on "Start the Django DDP service" on the Example Usage instruction at https://github.com/commoncode/django-ddp
I created a virtualenv,
I created a project named tutorial,
I followed the example usage instructions from the start until,
Every time I tried to run this command (DJANGO_SETTINGS_MODULE=tutorial.settings dddp) in shell I always get a response of "ImportError: No module named tutorial.settings"
P.S.: I even tried to package the project dir but still no luck.
It would seem the issue is that your project isn't on the PYTHONPATH.
I had this issue when I wanted to set DDDP to be called from a executable python file. So, I created a file called run_dddp.py and added this:
#!/usr/bin/env python
import os
import subprocess
if __name__ == "__main__":
new_env = os.environ
new_env['PYTHONPATH'] = '/path/to/your/project'
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "tutorial.settings")
subprocess.call(['dddp'], env=new_env)
That adds the location of your project to the path and passes it to dddp.
I suppose you could also just modify the dddp exectuable and add in sys.path.append(/path/to/your/project) there as well or just add it to the path before calling DDDP every time, too. But the file above was just easier for me.
I've been trying to port a Maya based python project over to PyCharm but I'm having trouble running unit tests.
Maya provides its own python interpreter (mayapy.exe) with a zipped version of the python stdlib (in this case, 'Python27.zip') AFAIK there's nothing special about the stdlib here, but to run the native maya functions you have to use MayaPy rather than a generic python.
The problem appears to be that the jetBrains test runner (utRunner.py) wants to get os.system and it's barfing because it uses a specific import routine that doesn't allow for zip files. It tries this:
def import_system_module(name):
if sys.platform == "cli": # hack for the ironpython
return __import__(name)
f, filename, desc = imp.find_module(name)
return imp.load_module('pycharm_' + name, f, filename, desc)
and fails with this error:
ImportError: No module named os
I think because this is bypassing the zip import hook.
There's one solution posted here, which is basically to unzip the standard library zip. I'm reluctant to do that because I might need to run the tests on machines where I don't have admin rights. I'm also reluctant to patch the code above since I'm not clear how it fits in to the whole test process.
So: how to run tests with a zipped standardlib using PyCharm, without unzipping the library or tweaking the PyCharm install too much?
For lurkers: I was unable to find a better solution than the one linked above, so it was necessary to unzip the 2.7 standard libary into a loose folder. Inelegant, but it works,.
There was a further wrinkle that maya users need to watch out for: PyCharm does not like tests which run Maya.standalone -- the standalone session did not exit properly, so when running tests (in onr ore more files) that called
import maya.standalone
maya.standalone.initialize()
The pycharm test runner would hang on completion. After much frustration I found that adding an atexit handler to the test code would allow the standalone to exit in a way that PyCharm could tolerate:
def get_out_of_maya():
try:
import maya.commands as cmds
cmds.file(new=True, force=True)
except:
pass
os._exit(0) # note underscore
import atexit
atexit.register(get_out_of_maya)
This pre-empts the atexit hook in Maya and allows the tests to complete to the satisfaction of the Pycharm runner. FWIW, it also helps if you are running MayaPy.exe from a subprocess and executing your tests that way.
I ended up just editing Pycharm's utrunner.py file. It already imports os at the top of the file, so I'm not sure why it calls import_system_module. The import command automatically handles zip files. Also if you put the maya.standalone in the runner file, you don't need to call it in any of your test files.
#os = import_system_module("os")
#re = import_system_module("re")
import re
try:
import maya.standalone
maya.standalone.initialize()
except ImportError:
pass
I'm using Pycharm 5.0.1.
I'm trying to get running the Huey task queue for python (it's a Celery alternative) and I'm stuck with starting the consumer with main.Configuration (as it's written in the tutorial). I know the huey_consumer is looking for the configfile somewhere in the python, but I cannot get it working according to the tutorial and I don't know why I should write a config file and load it as a module (instead of a file).
When I run huey_consumer.py main.Configuration it returns Unable to import "main".
Huey have this issue written in their common pitalls too, but it's not really helping either.
If there is somebody using Huey, please help me.
I had the same problem and solved it by adding the directory containing main.py to the PYTHONPATH. There was no need to copy huey_consumer.py
So the way this works is it tries to import the module "main". It would be equivalent to opening up a python shell and running:
>>> from main import Configuration
Perhaps you can reply with more information about your environment, the layout of your files, what you're running, etc.
I think you need to add an __init__.py file to the folder that contains main.py, ... else you cannot import anything as python will not consider this folder as a module.
What's the difference between a Python module and a Python package?
See comment by giulio-piancastelli
When I start the interactive django shell through manage.py, by executing
python -v manage.py shell
from the project directory, I see a lot of modules of format django.package.module getting imported in the verbose output but still I have to import them to use it in the shell.
The same happens when I just run the Python shell (with the -v argument). For example I see this in the verbose output,
import os # precompiled from /usr/local/gdp/lib/python2.4/os.pyc
but still i have to do import os to import and use the os module. What is being imported that am seeing in the verbose output and why I have to import them explicitly again to use them in the shell? Does Python load some essential modules while starting the shell or is it some kind of behind-the-scene magic?
-v traces the first import of a module -- the one that actually loads the module (executes its code, and so may take a bit of time) and sticks it into sys.modules.
That has nothing to do whether your interactive session (module __main__) gets the module injected into its namespace, of course. To ensure module 'goo' does get into the namespace of module 'X' (for any X, so of course including __main__... among many, many others), module 'X' just needs to import goo itself (a very fast operation indeed, if sys.modules['goo'] is already defined!-).
Python loads the site module implicitly when starting up, which may in turn import other modules for its own use. You can pass -S to disable this behavior.
They are getting imported (look at sys.modules) and references to the module are created in whichever modules have imported it.
When you do an import in your shell, if the module has already been imported, you will just get a copy of the reference to it in sys.modules