Forums

I am trying to set up a new Flask project. I clicked "Add a new web app", chose Flask and Python 2.6, at which point I'm asked to enter a path for the flask_app.py file. If I put the "right" answer:

/home/hy/Dropbox/dohs/webserver/xtiles/flas_app.py

I get "Permission denied: You do not have write permissions for directory /home" Can it be because my username on the machine ("hy") doesn't match my username on PythonAnywhere ("xtiles")? If so, is there a workaround? I tried changing /home to have ACLs 777, which is crazy (and didn't work -- changed it back). And I tried constructing a dummy directory under "/" with ACLs 777 and putting a symbolic link in there, which also didn't work...

Thanks for any help.

• Hy

Because your username on PythonAnywhere is xtiles, then it's in that user's home directory that you need to create your project -- you can't create it in another user's home directory.

You say that the directory you're specifying is the "right" one -- could you clarify?

Thanks very much for the reply -- I didn't realize that the PythonAnywhere username had to have anything to do with my Linux username (seems like they should be unrelated -- especially since, in the free version, the PythonAnywhere username becomes part of the URL to the website). So I guess I will have to create a user "xtiles" on my system and do my work there for this project.

(By the "right" directory I mean the one where I had intended to keep my work for this project.)

Thanks again.

Ah, I see. Normally one would write a Flask app so that it's not dependent on the precise location where the source code happens to be. Is there a particular reason why your code needs to be in a specific location?

Not at all. But I work as username "hy", so it should be somewhere under /home/hy, and I'd like it backed up automatically, so somehwhere under /home/hy/Dropbox would be ideal. When I chose a username for PythonAnywhere I was thinking about the project and the website; "xtiles" makes sense, but there is no such user on my machine. In any case, I can create one, and I might be able to do some symbolic link and creative access control magic so that I can work on it without actually logging in as xtiles (have to play with that...).

• Hy

why don't you just put the answer "/home/xtiles/Dropbox/dohs/webserver/xtiles/flas_app.py" when PythonAnywhere is asking you for the location of your files?

This location is the location on the PythonAnywhere file system, not on your local machine.

This location is the location on the PythonAnywhere file system, not on your local machine.

This is the part I didn't understand at all...

In my defense, I started on the Flask Deployment page, which has a link to the PythonAnywhere page describing how to deploy a Flask application. I followed the instructions there, which got me to a page asking where I wanted to keep my source files. I know where I want them -- I have them there already. There's no indication that the location we're talking about is on your system -- why would I care where the files are on your system?

Anyway, my misunderstanding, thanks very much for setting me straight.

OK, I see why that's confusing, I'll see what we can do to clarify the help page. The reason you'd care where the files are on PythonAnywhere is because it's your slice of our system.

Some people (with paid accounts) run a bunch of different websites from their PythonAnywhere accounts, so of course they do care where exactly their files are kept. And, of course, you can also keep different branches of your code -- perhaps the version you're working on on your own computer is your development version, with stuff you're not willing to push live yet, while the version on PythonAnywhere is a live version with bugfixes. (If you wind up doing things that way, I strongly recommend you use git to manage the different versions!)

Thanks, makes sense.

For what it's worth, I'm very pleased with my new PythonAnywhere account. I had a Flask application running on OpenShift for the past year or so, and recently got notified from them that I had to migrate to their new platform. Which I tried to do; very difficult! In the end I gave up and went looking for other options. Your PythonAnywhere platform is so much simpler than what I was using at OpenShift -- I love the CLI window, and the ability to get my files up without having to have them under source control (one day I should become a git expert, but it's just me working on these, and I have other things to do...) So thanks very much for the excellent platform. I hope that one day my site will be popular enough to justify paying you for it.

(Check it out if you like: http://xtiles.pythonanywhere.com/)

• Hy

Thanks, it's good to hear things are working well right now apart from that initial confusion! Out of interest, was there a specific thing that OpenShift did that was problematic for you? It would be useful to know if there's anything we should definitely not do as our service evolves over time :-)

Love the game, BTW. I can see that being very addictive.

A number of things about OpenShift make it more complicated:

1) I guess my biggest complaint is that it's entirely dependent on git. Probably that's fine, and even good, if you're a professional, but for the hobbiest it's another learning curve. I got it working well enough to install my software and make updates now and then, but I never mastered it (what's my "github-id", what's my "repository name" -- these were things I needed to know to migrate to their new version; probably trivial but not to me!). The ability to upload a zip file, open a CLI running bash, and unzip is really beautiful, as is the ability to just upload a new version of a file through a simple web interface when I want to change something.

2) And the more I think about this the more it annoys me: What kind of service is that, to tell your customers that you're changing your architecture and so they have to do a bunch of work or you'll stop supporting them? Crazy! Improve your architecture if you want, but keep supporting your existing customers.

3) Can't say that I understand what it is, but OpenShift has a "model" that you have to fit yourself into, which ends up meaning a handful of config files you have to set up. It's not just "name your program flask_app.py and you're good to go" like it is on PythonAnywhere. They're not necessarily especially hard, but the less I have to know about how the hosting platform works, the better. An example: my site uses a SQLite database. On PythonAnywhere I just put it in a directory under /home/xtiles, and I can hardcode the path to that in my program. On OpenShift I have to use a system environmental variable to figure out where it is -- not rocket science, of course, but also not as simple as '/home/xtiles/data/game.db' or some such.

And finally, I'll just add that I can't imagine this kind of support from RedHat, I really appreciate your concern both with my little problem and with making your platform all it can be.

(And thanks for the encouragement on the game -- I'm hoping to make it my retirement plan, so I love getting positive feedback!)

• Hy

Excellent, many thanks for the details! The whole git workflow is a really good one (and I'd certainly recommend you give it a look when you have a chance), but yes -- forcing people to use it up-front seems like it's more about making things easier for the system maintainers than for the customers. We do support it, but I can't see us ever making it a requirement.