This is a weird question but its been driving me bonkers for the last 3 hours. I wanted to play around with a pyramid based cms Kotti and I made a mistake by installing it using easy_install first(sudo easy_install kotti). I'm getting weird behavior and I'm not sure if its the way the program itself or the way I installed it.
I want to change some parts of the code and see how it works but my changes are not taking effect. After I installed it via easy_install I did:
virtualenv mysite --no-site-packages
bin/easy_install pyramid
git clone https://github.com/Pylons/Kotti.git
cd Kotti
sudo ../bin/python setup.py develop
../bin/pserve app.ini --reload
I went to 127.0.0.0:5000 and saw it was working. The first page has text that says "Congratulations! You have successfully installed Kotti." so I went into the kotti directory and did a grep "Congratulations" *.* and found it was coming from populate.py. So I opened the file and changed the line to a different piece of text and saved. Because I have the --reload flag on pserve I noticed it reloaded my code on the terminal and when I went back to the site the data did not change.
I'm so confused because the server reloads when I change the python code, so it sees the change but its not reflected in the browser(just to test if its the browser cache I tried it using different browsers and cleared the cache).
Any ideas?
When you run a Kotti web application for the first time, as with most CMS systems, it runs a set of data population methods (including that populate.py code you mentioned) to set up a database and insert all the content you see. The --reload is only telling the deployment server to watch for file changes as you work on the file system.
If you want to rerun the installation/population code then you need to delete the created database. If you haven't made any changes from their example app.ini file it will likely be Kotti.db.
Alternatively use the CMS to make the changes, as is intended by the CMS systems.
Running python -v will show all the imports
Related
So I have this Python pyramid-based application, and my development workflow has basically just been to upload changed files directly to the production area.
Coming close to launch, and obviously that's not going to work anymore.
I managed to edit the connection strings and development.ini and point the development instance to a secondary database.
Now I just have to figure out how to create another copy of the project somewhere where I can work on things and then make the changes live.
At first, I thought that I could just make a copy of the project directory somewhere else and run it with different arguments pointing to the new location. That didn't work.
Then, I basically set up an entirely new project called myproject-dev. I went through the setup instructions:
I used pcreate, and then setup.py develop, and then I copied over my development.ini from my project and carefully edited the various references to myproject-dev instead of myproject.
Then,
initialize_myproject-dev_db /var/www/projects/myproject/development.ini
Finally, I get a nice pyramid welcome page that everything is working correctly.
I thought at that point I could just blow out everything in the project directory and copy over the main project files, but then I got that feeling in the pit of my stomach when I noticed that a lot of things weren't working, like static URLs.
Apparently, I'm referencing myproject in includes and also static URLs, and who knows where else.
I don't think this idea is going to work, so I've given up for now.
Can anyone give me an idea of how people go about setting up a development instance for a Python pyramid project?
The first thing you should do, if it's not the case, is version control your project. I'd recommend using git.
In addition to the benefits of managing the changes made to the application when developing, it will aldo make it easier to share copies between developers... or with the production deployment. Indeed, production can just be a git clone of the project, just like your development instance.
The second thing is you need to install the project in your Python library path. This is how all the imports and includes are going to work.
I'd recommend creating a virtual environment for this, with either virtualenv or pew, so that your app (and its dependencies) are "isolated" from the rest of your system and other apps.
You probably have a setup.py script in your project. If not, create one. Then install your project with pip install . in production, or pip install -e . in development.
Here's how I managed my last Pyramid app:
I had both a development.ini and a production.ini. I actually had a development.local.ini in addition to the other two - one for local development, one for our "test" system, and one for production. I used git for version control, and had a main branch for production deployments. On my prod server I created the virtual environment, etc., then would pull my main branch and run using the production.ini config file. Updates basically involved jumping back into the virtualenv and pulling latest updates from the repo, then restarting the pyramid server.
I'm trying to generate PDF file from Latex template. I've done it in development environment (running python manage.py straight from eclipse)... but I can't make it work into the server, which is running using cherokee and uwsgi.
We have realized that open(filename) creates a file owning to root (also root group). This isn't taking place in development environment... but the most strange thing about this issue is that somewhere else in our code we are creating a text file (latex uses is a text file too), but it's created with the user cherokee is supposed to use, not root!
What happened? How can we fix it?
We are running this code on ubuntu linux and a virtual environment both in development and production.
We started following some instructions to do it using python's temporary file and folder creation functions, but we thought that it could be something related with them, and created them "manually" in order to try to solve this issue... but it didn't work.
As I've said in my comments this issue was related to supervisord. I've solved it assigning the right path and user into "environment" variable of supervisord's config file.
This is an old app, running since about two years on Heroku. Now suddenly, when I deploy (standard git push), it breaks the Python interpreter, both on regular and one-off dynos. Here's what it looks like:
$ heroku run python
Running `python` attached to terminal... up, run.8338
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Further pushes, heroku restart, scaling the dynos to zero and back up, that all doesn't fix it.
The only changes contained in this deployment which I could imagine being related to this problem are: gevent upgraded from 0.13.6 to 1.0.1 and the introduction of a runtime.txt (before there was none, resulting in 2.7.4, now there's one for 2.7.6).
I rolled all of this back to no effect, however. In fact, I went back about 30 commits (the deployment contained maybe five) and pushed that and the app is still broken.
Rolling back with heroku rollback is the only way I've found to take the app back into a usable state. But of course that doesn't help me going forward.
What might cause this? Can I somehow rebuild my whole app environment from scratch?
EDIT 1: I opened a shell in a one-off dyno and I can see the libpython2.7.so.1.0 file there:
/ $ ls -la /app/.heroku/python/lib/libpython2.7.so.1.0
-r-x------ 1 u49295 49295 5694572 2014-06-03 23:39 /app/.heroku/python/lib/libpython2.7.so.1.0
Of course I don't know if that's where it's supposed to be.
Somehow certain apps did not upgrade properly. A temporary fix to locate the correct python library:
heroku config:set LD_LIBRARY_PATH=/app/.heroku/python/lib
Kenneth Reitz from the Python team here.
So, we're rolling out security updates to the version of Python that we have installed on our base system. Customers shouldn't be affected by this in any way, because their apps use their own version of Python, and because we set local runtime-specific (such as LD_LIBRARY_PATH) in a .profile.d scripts, outside of user-set configuration.
However, we allow power users to override these environment variables with $ heroku config. That's basically what the application was doing — although, not knowingly. This was an accidental side-effect of a much, much older Heroku. In older days, we couldn't have any runtime-specific configuration without being a part of user configuration. This is why your application had an LD_LIBRARY_PATH config set, and this is what caused this bug.
Because of this, I've disabled the overridability of LD_LIBRARY_PATH for Python apps, and all should be well moving forward.
Thanks for being a part of the gradual rollout process, and thanks for helping us get to the bottom of this regression. I'm very sorry for the inconvenience.
Are you using the default Python buildpack? Heroku is in the process of updating the Stack image, and especially if you're not using a current buildpack, there may be incompatibilities.
To see if you're using a default buildpack, run
$ heroku config | grep BUILDPACK_URL
Please contact Heroku support if you think this might be the cause.
I'm trying to set up an Ubuntu LAMP server. The machine would be dedicated to one site, and the site has a few .py files I'm working on. It would seem I have the PHP and MySQL up and running, but the Apache doesn't seem to be executing the .py files (just downloading them).
I then noticed that there seem to be two Interpreters, one at /usr/bin/python and one at /usr/local/bin/python
Which one should my headers be pointing to? At the moment I have !#usr/local/bin/python
I note that I also could have a problem with apache2.conf, but I'm not so sure. Using a virtual host I added a cgi handler (and tried mod_python) with no luck. I could post up the whole vitrual host from apache2.conf of that would help.
I've chkmod +rwx *.py in the site folder. Perhaps I should split this into to two posts, but I think they might be related.
Thanks
You can let the environment decide, which should mean it'll execute using whatever executable is run when you run python in your shell:
#!/usr/bin/env python
# Code goes here
I had a similar issue when running fast-cgi and I was told there is no way to fix it: Files being served are stale / cached ; Python as fcgi + web.py + nginx without doing custom work. I was told to use the python method, which invokes a local "web server" to host the python page.
Even doing that, the files served are stale / cached. If I make edits to the files, save and refresh, the python web server is still serving the stale / cached file.
The only way to get it to serve the modified file is to kill (ctrl+c) the script, and then restart...this takes about 5 seconds every-time and seriously impedes my development workflow.
Ideally any change to the script would be reflected next time the page is requested from the web server.
EDIT
#Jordan: Thanks for the suggestions. I've tried #2, which yields the following error:
app = web.application(urls, globals(), web.reloader)
AttributeError: 'module' object has no attribute 'reloader'
Per the documentation here: http://webpy.org/tutorial2.en
I then tried suggestion #4,
web.config.debug = True
Both still cause 'stale' files to get served.
Understandably you want a simple, set it up once and never worry about it again, solution. But you might be making this problem more difficult than it needs to be.
I generally write applications for an apache/modwsgi/nginx stack. If I have a caching problem, I just restart apache and voila, my python files are re-interpreted. I don't remember the commands to restart apache on all of my different boxes (mac's, ubuntu, centos, etc), and I shouldn't need to.
That is what command line aliases are for...
A python application is interpreted before it is run, and when run on a webserver, it is run once and should be considered stateless. This is unlike javascript running in a browser, which can be considered to have state since it is a continually running VM. You can edit javascript while it is running and that is probably fine for most applications of the language.
In python you generally write the code, run it, and if that doesn't work you start over. You don't edit the code in real time. That means you are knowingly saving the source and changing contexts to run it.
I am betting that you are editing your source from a Graphical IDE instead of a command-line editor like vi or emacs (I might be wrong, and I'm not saying there is anything 'wrong' with that). I only write iOS applications using an IDE, everything else I stick to ViM. Why? Because then I am always on the command line, and I am not distracted by anything (animations, mouse pointers, notifications). I finish writing my code, i quickly type ':wq' (write and quit), and then quickly type 'restartweb' (actually i usually type 're' then <\tab> to auto-complete) which is my alias to whatever the command to restart apache is. Voila my python is reinterpreted.
My point is that you should probably keep it simple and use something like an alias to solve your problem. It might not be the coolest thing you could do. But it is what Ninja coders have been doing for the last 20 years to get work done fast and simple.
Now obviously I only suggested a solution for apache, and I have never used web.py before. But the same possible solution still applies. Make a bash script that goes in your project directory, call it something like restart.bash. In it put something like:
rm -r *.pyc
Which will recursively remove all compiled pyc files, forcing your app to reload. Then make an alias in your ~/.bashrc that runs that file
Something like:
alias restartproject="bash /full/path/to/restart.bash"
Magical, now you have a solution that works everywhere, regardless of which type of web server you choose to run your application from.
Edit:
Now you have a solution that works everywhere but on a Windows IIS server. And if you are trying to run python from Windows, you should probably Stahp! hugz
We are using virtualenv right? :) We want to keep our python nice and system-agnostic so we can sell it to anyone right? :) And you should really check out ViM and emacs if you don't use them... you will bang your head against the wall for a week getting used to it, then never want to touch a mouse again after that.
Right, so Python is a compiled language when run on a web server. It's outputting a .pyc file that's the compiled version. Your goal is to tell the web server that the .pyc file is out of date and is no longer valid.
You have a few options:
Delete the relevant .pyc file
For web.py, use the reloader middleware
Send it a HUP signal (I'm lazy and usually do killall -SIGHUP python). You can do this automatically with a file watching tool like watchdog (thanks barracel).
web.config.debug = True should be the default in your application
None of those options are working for you?