I have one web app tied to my username.pythonanywhere.com - which is great!

But now I need to test a different Django web app, and I don't want to wreck what I have already.

But when I click to add another web app, it wants me to come up with a "real" registered domain name. For expanded testing I would not mind, but for this early stage I just want something, anything - no matter how ugly - so I can get some critical tests done.

I'm hoping there is some clever way to add a suffix or prefix to my user name to get a few Quick and Dirty domains for testing.

(wink)

You could create additional accounts for your testing and once you have the code sorted out, move it to your main account to host with your domain.

But I'd definitely +1 the idea of letting us fill up our slots with projects whether we have a domain for them or not. Perhaps allow us to point them to a folder instead of a domain like:

https://a2j.pythonanywhere.com/some_project_folder

☺

If you want to put a project into a sub-folder, can't you just wrap your code into a trivial app which just routes the requests to other code based on the URL? I realise this means some minor changes to the code, but the core of the application probably won't need to change (unless you've use absolute URLs for SEO reasons, in which case you should always template them on some centrally-configured base URL anyway to make it easy to move your app around in the URL space).

If the PA devs were to allow any sort of multiplexing I'd expect it to be on subdomains rather than folders. It seems cleaner to me to maintain a clear split between the host portion of the URL being the PA hosting's responsibility and the path portion being the web application's responsibility. Splitting by path would need the hosting system to run some sort of stub WSGI app that then delegates to the user's own code, which doesn't seem ideal, or some sort of URL rewriting in nginx which also doesn't seem particularly clean.

You could use a WSGI middleware to do the dispatching for you. There are a number of options, but the ones that look like they would be the easiest to use on PythonAnywhere are:

1. Werkzeug DispatcherMiddleware There are some examples of use here (search for "Combining Applications"). In the first example, backend and frontend are the WSGI apps that you'd like to combine. Werkzeug is already installed on PythonAnywhere, so it should be easy to get working.
2. selector is not installed on PythonAnywhere, but it looks more powerful (and harder to understand). You'll need to install it locally or into your virtualenv, if you're using one.

I think it would be a good idea for us to support something like this, so I've raised a ticket to do that.

Heh. You underestimate how lazy I am!

I hacked my wsgi file to point to the new project....

Sub-optimal in that I may - one day - want to have multiple test project running....

And in true Agile form, I'll deal with the issue then....

Heh.

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall

How are you doing on the other two?

Yes, but this is from someone whose idea of a readable programming language is this:

''=~('(?{'.('+-).+}'^'[_@@_]').'"'.('>^-+-//_'^'}?___@@}').',$/})')

(If you're curious, I suggest cat | perl and pasting it in, as it's a bit of devil to escape from the shell on the command-line. Also, I can't claim any credit whatsoever, that belongs to this clever / sick individual)

Heh. Perl - the ultimate write-only language.

Does it work yet?

foot tap, tap, tap....

How about now?

If I worked here, it would be done. Everybody would have direct URLS right to all of their projects. Coffee and Beer would be FAXed right to your desk, as you need it. And the system would send the appropriate one depending upon your mood and needs.

There, I think that covers the other two areas. But so much typing, I need a nap now.....

@rcooke

Thanks

to

you!!!!

I didn't know we could make <hr />

Of course, now I do.

THANKS ☺

PS: I hope you enjoyed your nap.

Coffee and beer separately? That doesn't sound very Pythonic. Surely there should be one - and preferably only one - obvious beverage.

(If only that wasn't an April fool :-()

I'd certainly buy it.

Definitely - it's the glowing that tipped you off? (^_^)

(Oh right, if you try to buy it the next page kinda gives it away - d'oh).

Although, caffeinated beer is quite real. Not sure how easy it is to find these days, it was a bit of a fad.

So, have the Geniuses at PAW figured out a slick way to let us "host" or "switch between" multiple projects, (preferably in VirtualEnvs) yet?

With the gracious help of PAW Support, I have a "django-inventory" working with Django 1.2 now. I really don't want to disturb it, but I need to work on another problem.....

Related post: https://www.pythonanywhere.com/forums/topic/572/#id_post_4559

So, you've already figured out that you can hack the wsgi file for a given domain to get it to point to any project you want, right?

Over and above that, if you want to have several different sites running at the same time, you can create a web app for each. That can include subdomains of your main site. So, I have an app for www.obeythetestinggoat.com and another one for dev.obeythetestinggoat.com...

One thing we're probably not going to do is let people on the free or hacker accounts run more than one web app by default. The whole point is that you have to pay for that!

Of course, if you can figure out how to set up some clever domain-sniffing wsgi middleware redirector, you can probably avoid paying ;-)

Now this is weird. There is a link in topic 572 pointing here...and one above pointing there...☺

The problem with "hacking" WSGI is it does not "fix" the STATIC files settings. And if I try to add "all" of the different static settings I need at once I will likely get a conflict.

Cross-posting links are needed to help me find old topics.... Its not like there is a handy "watched posts" setting, or even a "show my posts" function.....

That's a good point. The "hack the wsgi file" instructions were great before we had static files, but now they're not very useful. I think that's something we need to fix and I'll raise a ticket for that.

Here is something interesting I tripped over today:

Using dynamicsites you can host multiple sites within a single domain. This may be the most common setup. This will allow different url mappings by subdomain. To do this you'll need to create a site object for the different subdomain sites.

Within the list of subdomains for a site, the first subdomain listed will be the default subdomain. If you want the default subdomain to be blank, put '' (single quote empty string) as the first subdomain in the subdomain list in the admin panel for sites.

• http://blog.uysrc.com/2011/03/23/serving-multiple-sites-with-django/
• https://bitbucket.org/uysrc/django-dynamicsites/src

Very cool.

Any news on this front?

Guys, please help me understand, no doubt I am being stupid, but:

Once you have a web-developer account, and you own a domain, you can set up as many web apps as you want, just by using a different subdomain and a different CNAME for each, right?

so

testing-site-1.my-domain.com
testing-site-2.my-domain.com
testing-site-3.my-domain.com

can all have separate web apps on pythonanywhere, with different code and different static file mappings. Meanwhile, www.my-domain-com can be your "live", site, you can even host it somewhere other than pythonanywhere if you really want. You never need to publicize all the testing-site-xs, so your users never need to see them...

What more do you want? Is it that you don't like having to set up a separate CNAME every time, because your domain registrar has an annoying control panel? (we certainly know something about that. <cough-Joker-cough>). Or is it that you don't want to shell out the $5 per year for a domain registration? Or am I missing something obvious? Apologies if so...

As I think about it, I'm imagining it is the annoyance of having to set up a new CNAME each time, right? Perhaps we could build a feature where we generate a throwaway GUID pythonanywhere subdomain on request, like

guid-xyz-abc-123-abc-a123-def.pythonanywhere.com

For quick throwaway webapps... Then you guys would only have to click one button, rather than have to fight with your registrar's control panel... That might be an interesting idea... And something like what Heroku et al do.

Is that what you guys would like?

I can't promise we'd do it soon, there's lots and lots of stuff on the pile, but still, definitely something to think about for the medium term.

In the meantime, I can only recommend going to your registrar's control panel and setting up a bunch of CNAMEs in advance. If you do testing-site-1.mydomain.com and testing-site-2.mydomain.com and so on, do a dozen or so at once, then it's done, and done forever...

Most registrars will let you set up a CNAME for *.my-domain.com too, so that could work.

The other possible feature is a thing where you could set up several "inactive" web apps, and then choose to "activate" them by linking them to a domain... then you would be able to switch your domain from pointing at one web app to pointing at another.

Would that be preferable to the guid-based solution?

Instead of random GUIDs, would it be difficult to create subdomains of the default user domain attached to different web apps? Presumably you could restrict that feature to appropriate account types via the configuration interface. I can't see why adding subdomain.cartroo.pythonanywhere.com would be much different from adding any other arbitrary domain to the configuration except that it would require DNS changes on the PA side which could cause issues with DNS caching. Hopefully most providers would respect the TTL, however, which could be set lowish.

I think we could probably get by with setting up a *.domain.tld CNAME. I am not a good or even half way decent SysAdmin so I don't know any cons to this approach. I like cartroo's answer, but I am not sure how that would effect a site who has a cname set up for a production app at say: http://domain.tld or http://www.domain.tld... I am just ignorant on this aspect of web development in general. Shame on me and just one of many, many reasons why I choose PaaS over VPS. I go to Server Fault and search for CNAME and just get more confused...

Well, we'll have a think about it all! In the meantime, setting up multiple CNAMEs at your own registrar is the way to go...

@harry:

I like your second idea: "All you have to do is click one button instead of ..."

You have no idea how lazy I am.

Plus, it makes your system more useful and attractive to me (and others) as a test system.

Ok. What is becoming clear as I encounter new clients that want to see demos of different things, and have no existing project management system of their own, is my "standard" PAW free account demo needs two things:

1. Trac

2. Django

Which needs to be handled by Wsgi somehow.

One way is domain sniffing middleware. Detects if the incoming url is the Django base or the Trac base - which might be trickier with slug urls.

Another way is to have WSGI point to Django. And have the urls.py take only the Django urls (comment out the catch-all case). And then have it chain or pass on to Trac.

Not sure if that would mean calling Tracs dispatcher from inside urls.py?

(this is Rcooke on a test/demo account)

Could the Werkzeug DispatcherMiddleware help? It's at the bottom of that page.

Yes Glenn, werkzeug should help. I looked at "selector" too - don't think its needed for what I want though.

I tried to set werkzeug up on this account and it blew apart on me though!

Thing is, I can't even get just Trac working again. Could this be related to the software update today?

Hmm, one thing changed with web apps in the last release -- we fixed the current working directory to your home directory. Previously it was undefined, but perhaps you had some code that depended on whatever it happened to be?

Yeah, see my note about what happens if the virtualenv source command is not first in the wsgi file....