From pje at telecommunity.com Sun Apr 1 06:03:17 2012 From: pje at telecommunity.com (PJ Eby) Date: Sun, 1 Apr 2012 00:03:17 -0400 Subject: [Web-SIG] A more useful command-line wsgiref.simple_server? In-Reply-To: References:

<4BF6E0F8-C23B-481B-984A-131E418EC776@masklinn.net> <78F23365-A4D8-4817-B0BA-44304E85E5C0@masklinn.net>

Message-ID: On Fri, Mar 30, 2012 at 11:57 PM, Graham Dumpleton < graham.dumpleton at gmail.com> wrote: > On 31 March 2012 14:36, PJ Eby wrote: > > Why give them a __name__ at all? Aren't they scripts, rather than > modules? > > ISTM that not having a __name__ would also let things like pickles fail > > faster. That is, code that expected a module rather than a script would > > break right away. > > Because not having a __name__ attribute at all would make: > > if __name__ == '__main__': > ... > > fail straight away and people quite often had that in scripts so they > could run it directly as well with a pure WSGI server. > Well, they could always replace it with "if globals().get('__name__', '__main__')== '__main__':", I suppose. ;-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn at masklinn.net Sun Apr 1 16:32:00 2012 From: masklinn at masklinn.net (Masklinn) Date: Sun, 1 Apr 2012 16:32:00 +0200 Subject: [Web-SIG] A more useful command-line wsgiref.simple_server? In-Reply-To: References:

<4BF6E0F8-C23B-481B-984A-131E418EC776@masklinn.net> <78F23365-A4D8-4817-B0BA-44304E85E5C0@masklinn.net> Message-ID: On 2012-03-31, at 05:27 , PJ Eby wrote: > On Fri, Mar 30, 2012 at 2:22 PM, Sasha Hart wrote: > >> I do really like the idea of having a quick WSGI runner in the stdlib, >> > Regarding modules vs. files, I don't really care that much which way the > capability is spelled, as long as the file vs. module distinction is > explicit. "-m " isn't a lot to add to a command line, and neither is "-f > ". If there's no consensus, just require that one or the other be > specified, and inconvenience both groups of people equally. ;-) Let's go with that. I'm not sure if I should be using sub-commands or options so for now I've used options. UI changes from initial patch: * Exclusive options for getting the application callable from a script (via `exec`) or a module (using `importlib.import_module`) * Application name specification has been moved to an option (default: `application`) * Option to serve the request only once (default: forever) when mounting a custom application * Option to open a browser window/tab to the (host, port) specified (which still default to '' and 8000 respectively) > python -mwsgiref.simple_server -h usage: simple_server.py [-h] [-H HOST] [-p PORT] [-s SCRIPT | -m MODULE] [-a APP] [-1] [-b] Mount and serve a WSGI application. If no script or module is specified, mounts wsgiref.simple_server.demo_app optional arguments: -h, --help show this help message and exit -H HOST, --host HOST Host to listen on -p PORT, --port PORT Port to listen on (defaults to 8000) -s SCRIPT, --script SCRIPT WSGI script file to execute and get the application from -m MODULE, --module MODULE Python module to import and get the application from Script or module options: These options do not apply when mounting the demo_app -a APP, --app APP, --app-name APP Name of the application variable in the script or module, application if none is provided -1, --once Only handles a single request, then exits -b, --browse Launch browser to the served URL -------------- next part -------------- A non-text attachment was scrubbed... Name: simple_server.patch Type: application/octet-stream Size: 3147 bytes Desc: not available URL: From s at sashahart.net Mon Apr 2 06:54:36 2012 From: s at sashahart.net (Sasha Hart) Date: Sun, 1 Apr 2012 23:54:36 -0500 Subject: [Web-SIG] A more useful command-line wsgiref.simple_server? In-Reply-To: References: <4BF6E0F8-C23B-481B-984A-131E418EC776@masklinn.net> <78F23365-A4D8-4817-B0BA-44304E85E5C0@masklinn.net> Message-ID: On Fri, Mar 30, 2012 at 2:20 PM, Masklinn wrote: > On 2012-03-30, at 20:22 , Sasha Hart wrote: > > > > I am finding more reasons to dislike that -m: > > > > python -m wsgiref.simple_server -m blog app > > > > Beyond looking a little stuttery, it's really unclear. Anyone could be > > forgiven for thinking that -m meant the same thing in both cases > > And it does. In both case it means "use this module for execution". Hence > `-m`, as a shorthand for `--module`. > I don't agree, there are real differences. python -m runs e.g. what is in __main__.py and this is effectively a script: the interface is defined by things like sys.argv, environment variables, exit code, stdin/stdout. yourtool -m asks a module to put a callable into a namespace, the name of the callable must be known to decide which callable to use. a simple http server must run and repeatedly call the callable according to WSGI convention, not a script interface. Typically there is some kind of event loop, etc. The things 'executed' are different and they are 'executed' in quite different ways. So while you can use -m (or -xyz or -rm-rf) I have the opinion that it's a little more confusing and a little more long-winded than makes sense to me as a clean one-liner for newbies, partially because I think it suggests a misleading parallel. But this is just feedback; if you don't like it, then just get more feedback. My vote is for whatever gets consensus as easiest for users who have a use for the thing. If you get a patch in, great. If I don't like it then I will just recommend that (still pretty trivial, conceptually clear) wsgiref recipe or gunicorn or whatever has nailed the extreme simplicity required for this case where you are avoiding a 'real server' deploy. > so I see no gain of understanding by reusing the convention. python -m > doesn't take a > > second positional argument, either. > > I'm not sure why that would matter. > What it could matter (for what it's worth) is that two different calling conventions is more for a newbie to keep straight, for a '-m' which is supposed to mean one thing. > > > You can't write '-m blog app -m > > wsgiref.simple_server' or '-m blog -m wsgiref.simple_server blog' > > Naturally, because this makes no sense at all, the tool being invoked > to start the server is all of `python -mwsgiref.simple_server`. But > that's the very basics of the -m option. > It is only natural for people who have strong domain knowledge of Python, for whom the proposed feature is redundant. For people who don't care about Python or are just starting, it is not safe to assume detailed knowledge of the -m option to the python executable. Many utilities allow the same flag to be repeated to supply multiple arguments, for example; the interpretation of -m and the rest of the command line here is not unprecedented, but also not just obvious to every bash user. If this is easy, how hard is it to paste in the wsgiref recipe or run gunicorn? Take it or leave it, my input is that this has no reason to exist in stdlib unless it is at least as simple. But as I said before, if you get a patch in then that's great. I fail to see why that would be any more troubling than > `python -mcalendar -m 6`. Or require any more specifics. > I think 'draw six calendars across' is not at all confusable with 'run the calendar module as a script' because that utility is so simple. The one under discussion is at least somewhat more complex, since you are asking one module to run as a script which imports another module and picks out a callable and starts an HTTP/WSGI server. We can keep track of that without any trouble, but we are also subscribers to Web-SIG. I will likely never use that calendar one-liner in my life, nor recommend it to any newbie I am trying to help. Whether it is good or bad, it matters very little. If you get a patch into stdlib with really simple syntax then I will evangelize it right after 'hello world'. If not, there are other options which are also okay. > > > On reflection, I feel strongly that a module name should be the default > > positional arg, not a filename. I agree with PJ Eby that pointing > directly > > at a file encourages script/module confusion. I would add that it > > encourages hardcoding file paths rather than module names, which is > brittle > > and not good for the WSGI world (for example, it bypasses virtualenvs and > > breaks any time a different deploy directory structure is used). > > Not sure how that makes sense, it uses the Python instance and site-package > in the virtualenv, there is nothing to bypass. > The problem is that you get scripts coded directly against Z:\WORK\FROB\FROB2\FARPLE.PY instead of correctly searching for farple on PYTHONPATH (thus separating the concerns of how/where to install farple from ones of how to get it). If you write a script which hardcodes module paths, it is asking for exactly the same file regardless of what virtualenv you are in. I fully understand why the python interpreter takes file arguments. In web apps we are not talking about just running a file through the interpreter any more. WSGI doesn't involve 'running' scripts, but rather importing modules which contain WSGI application callables. Here we are talking about how to tell python to import a file by its filename, when Python itself already provides a clearly better way of finding things. Now I reckon you are seasoned and you know about those subtleties, but if I am just switching from PHP and you teach me to specify this with file paths then that is setting me up for frustration down the line, when I either have to deal with correct imports or I hit the wall of the 'import from py files' approach. > > > Of course, this also means no '-m'. Then the typical use case is really > just > > > > python -m wsgiref.simple_server blog > > > > A second positional arg is both a new convention and not an explicit one, > > where I would prefer either an existing implicit convention or a new > > explicit one. > > What is not explicit in having an explicit argument, that it's a positional > one instead of an option? How is a colon "more explicit"? > Well, that isn't what I said... I said that I would prefer EITHER an existing implicit convention (e.g. the widely used colon, which also made sense to me from the moment I saw it) OR an explicit convention (e.g. not allowing a second positional argument, only a labeled argument if a second argument were needed). The explicit one is wordy but discoverable. The implicit one is clean and allows me to transfer knowledge from myriad other tools using the same convention. The second positional arg has the disadvantages of both - neither discoverable, as it lacks a label nor does it benefit from sharing a convention with other tools (the latter has a little relevance to me when I wish to teach others, as well). This is why I was -1 on the second positional arg, and +1 on EITHER of the other two options, which have different pluses and minuses. > > > I think PJ Eby is right that the colon convention is only for modules, > and > > I think following gunicorn's lead here would result in a nicer interface > > than forcing (say) --module > > > > python -m wsgiref.simple_server blog:app > > The colon is no more explicit than a second positional argument. In fact, > it is significantly less so since it can not be separately and clearly > documented and the one positional parameter needs to document its parsing > rules instead. > I am sure that is slightly easier to write, anyway. This attribution of 'explicit' to the colon convention is probably a misunderstanding; I never said that (although I find it strange to say that the second positional arg is in any way more explicit, particularly when it is inventing a convention for referring to WSGI callables). The virtue of the colon syntax for me is that it fully covers the case which needs to be supported without any --args (simple, clean looking) and while allowing transfer of knowledge between this and just about every other tool out there which names WSGI callables. It's close to the simple Python notation for referring to the object - perhaps it could be better though? > > > If there is a need to point at a filename, I agree that it should be done > > explicitly. > > > > python -m wsgiref.simple_server --file=~/app.py > > > > (or whatever the flag should be called). To me this seems like a small > cost > > to allow the colon by default without possibility of confusion or overly > > fancy parsing. > > 1. It also does not work considering you can't specify the application's > name in that scheme, so piling on yet more complexity would be > required and there would be two completely different schemes for > specifying an application name. I don't find this appealing. > I guess the problem is that you are indirectly specifying the namespace, via a filename to be imported, and then directly specifying the name. All this (including cross-platform issues) is so much easier if you just use Python's conventions for finding and referencing modules and names in namespaces. But for whatever reason, you must import Python modules by filename (something I'll never do again, for reasons already laid out). Yet WSGI requires a name to be specified, so you end up with some kind of awkward hybrid specification. I certainly do not suggest trying to invent a new convention, but if you want to then you just need to pick a portable delimiter for the command line. Maybe a second positional arg or --app= for the cases where you are importing from a file and do not want 'application' and must have a one-liner rather than setting up the project. I have no reason to care because I will never use or teach this case. I think this is the interesting question: what convention already exists in Python for naming a particular object in an imported module? > 2. You seem to have asserted from the start that the default should be > mounting modules, but I have seen no evidence or argument in favor of > that so far. > In a way you do not have any choice but to 'mount modules': WSGI does not provide a mechanism to 'run a program' without picking a callable Python object out of a namespace, implying an import. My intention was to offer feedback, on the assumption that the idea was being thrashed out publicly. I believe I actually have offered some supporting reasoning for why I like the module path better as a default, even though you reject it. But ultimately, much of this is or verges on bikeshedding. Now our exchange has taken on a negative tone that I would not have chosen. I have written to clarify some misunderstandings, but I will not bother offering further unwanted feedback. I hope you will look for more input and develop a better consensus. Defaulting to scripts not only works with both local modules and > arbitrary files and follow cpython's (and most tools's) own behavior, > but would also allows using -mwsgiref.simple_server as a shebang > line. I find this to have quite a lot of value. > The python interpreter runs scripts, i.e. processes which interface with sys.argv and stuff like that. So of course it needs to take file paths. But imports are not typically done with file paths, and WSGI app-finding is either imperatively about importing or declaratively about Python namespaces - not file paths or scripts, as in CGI. Python imports are conventionally done by a path like frob.bar rather than a filename, which has problems (I think this is why we don't "import c:\work\frob\farple.py" at the top of our files, or run "python -m /usr/lib/python3.2/wsgiref.py simple_server". You must also specify a name for the app object, and it happens that the conventions around specifying names in namespaces dovetail pretty closely with the conventions around imports. (e.g.: from frob import app, import frob.app). Given that the operation required is an import and then a lookup, it seems more natural to me to use Python notation or something trivially related to it, rather than OS-specific filesystem notation. But I am sure this is just another disagreement and that's fine with me. I would personally not +x a module file just to serve an app with wsgiref from the hashbang line; it's clever but I can't come up with any real benefit. A case where I'm serving with wsgiref already has to be pretty trivial and I'm not going to couple to it *from inside the module itself* when it is so darned easy to just run the module from several nice python test servers (also portable and I can use autoreload, etc.) But if this is desired by many others, I'd agree it's a good factor to consider. Cheers Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Mon Apr 2 07:08:06 2012 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Mon, 2 Apr 2012 15:08:06 +1000 Subject: [Web-SIG] A more useful command-line wsgiref.simple_server? In-Reply-To: References: <4BF6E0F8-C23B-481B-984A-131E418EC776@masklinn.net> <78F23365-A4D8-4817-B0BA-44304E85E5C0@masklinn.net> Message-ID: On 2 April 2012 14:54, Sasha Hart wrote: > I would personally not +x a module file just to serve an app with wsgiref > from the hashbang line; it's clever but I can't come up with any real > benefit. A case where I'm serving with wsgiref already has to be pretty > trivial and I'm not going to couple to it *from inside the module itself* > when it is so darned easy to just run the module from several nice python > test servers (also portable and I can use autoreload, etc.) But if this is > desired by many others, I'd agree it's a good factor to consider. When using CGI or FASTCGI, with a hosting system where an executable script needs to be supplied, it is beneficial to be able to say something like: #!/usr/bin/env python -m cgi2wsgi #!/usr/bin/env python -m fcgi2wsgi where the rest of the script is the just the WSGI application. I have implemented this for CGI as an example at: https://github.com/GrahamDumpleton/cgi2wsgi I have done it for FASTCGI using flup as well before but that isn't available anywhere. Graham From graham.dumpleton at gmail.com Mon Apr 2 07:21:14 2012 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Mon, 2 Apr 2012 15:21:14 +1000 Subject: [Web-SIG] A more useful command-line wsgiref.simple_server? In-Reply-To: References: <4BF6E0F8-C23B-481B-984A-131E418EC776@masklinn.net> <78F23365-A4D8-4817-B0BA-44304E85E5C0@masklinn.net> Message-ID: On 2 April 2012 15:08, Graham Dumpleton wrote: > On 2 April 2012 14:54, Sasha Hart wrote: >> I would personally not +x a module file just to serve an app with wsgiref >> from the hashbang line; it's clever but I can't come up with any real >> benefit. A case where I'm serving with wsgiref already has to be pretty >> trivial and I'm not going to couple to it *from inside the module itself* >> when it is so darned easy to just run the module from several nice python >> test servers (also portable and I can use autoreload, etc.) But if this is >> desired by many others, I'd agree it's a good factor to consider. > > When using CGI or FASTCGI, with a hosting system where an executable > script needs to be supplied, it is beneficial to be able to say > something like: > > ?#!/usr/bin/env python -m cgi2wsgi > > ?#!/usr/bin/env python -m fcgi2wsgi > > where the rest of the script is the just the WSGI application. > > I have implemented this for CGI as an example at: > > ?https://github.com/GrahamDumpleton/cgi2wsgi > > I have done it for FASTCGI using flup as well before but that isn't > available anywhere. I should probably add though that this is not the best way it could be done for FASTCGI. For FASTCGI you are better off making use of FASTCGI implementations wrapper mechanism as intermediary with it handling the loading. This is the approach that PHP under FASTCGI uses and why it is so easy for users, namely because system admins set it up with wrapper support. You don't see such niceties for Python where a system admin sets up that a .wsgi script file would be understood to be a Python WSGI application with no extra magic needing to be added to it by the user, even though not that difficult in principle. Thus why users need to resort to #! line and low level FASTCGI script in the first place. Graham From s at sashahart.net Tue Apr 3 05:33:02 2012 From: s at sashahart.net (Sasha Hart) Date: Mon, 2 Apr 2012 22:33:02 -0500 Subject: [Web-SIG] Simple entry point discovery (was: A more useful command-line wsgiref.simple_server?) Message-ID: On Mon, Apr 2, 2012 at 12:08 AM, Graham Dumpleton wrote: > > When using CGI or FASTCGI, with a hosting system where an executable > script needs to be supplied, it is beneficial to be able to say > something like: > > ?#!/usr/bin/env python -m cgi2wsgi > > ?#!/usr/bin/env python -m fcgi2wsgi > > where the rest of the script is the just the WSGI application. > > I have implemented this for CGI as an example at: > > ?https://github.com/GrahamDumpleton/cgi2wsgi > > I have done it for FASTCGI using flup as well before but that isn't > available anywhere. That's a clever trick for CGI and a great reason to +x a script, since it's so helpful to people who need to deploy against CGI for any reason, but don't want to couple to CGI in the long run. I wouldn't personally use hashbangs with wsgiref because if I can run a Python interpreter, I have equal access to excellent pure-Python servers which are - not to slight wsgiref - miles ahead (e.g. concurrent requests, easy config, reloading). And it's not unlikely that I can just deploy locally on the same server I use in production. The use case I can imagine, if stdlib acquired a good server, is that someone writes the next Jenkins and wants to let *nix users check it out real quick by just running a script. But that case is already completely handled with a __name__ == __main__ clause at the bottom, which is also portable. > You don't see such niceties for Python where a system > admin sets up that a .wsgi script file would be understood to be a > Python WSGI application with no extra magic needing to be added to it > by the user, even though not that difficult in principle. That's a very appealing idea... Is anything really necessary besides a convention for finding a single WSGI application callable in a given directory? (i.e.: to do the job of e.g. the WSGIScriptAlias directive, only inside a directory.) To flesh out how easy this could be: * could have __init__.py put a WSGI callable called 'application' in its namespace. * Or if that is too inefficient for servers to discover, it might be done in __main__.py (still retrievable using `from foo.__main__ import application` - though maybe this is an abuse of the purpose of __main__.py since we are not running a process so much as importing just to get a Python object which doesn't know if it will be run with threads, processes, greenlets, etc.) * Or if we want to avoid spuriously running __main__.py (e.g. what if it runs a blocking process) then just pick a specially named Python file. __wsgi__.py or some such. * Or if importing things to yield the application is a concern, a text file like 'web.txt' which simply reads 'foo.app' or even 'foo:app' to point to the object named app inside foo.py. Then the server loads however it wants to. If people just agreed arbitrarily on (say) "__wsgi__.py" and "application" it would work as soon as implemented (pretty easy). What have I missed? From graham.dumpleton at gmail.com Fri Apr 13 02:09:37 2012 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Fri, 13 Apr 2012 10:09:37 +1000 Subject: [Web-SIG] Move www.wsgi.org to Read The Docs In-Reply-To: References: <20110819075141.GA25554@transvection.de> <4E5B2066.6010702@gocept.com> <4E6B31AA.1020403@transvection.de> <41E4CF7F-1F21-42CA-8142-B97ABC6D2AB6@masklinn.net> <4E6BB7FA.4050707@transvection.de> <4E965653-DDD1-4471-9952-84EC9A87C26E@masklinn.net> <4E6BBF51.5050907@transvection.de> <5139BF78-ED40-410F-A361-D0E441451327@masklinn.net> <4E7709A6.4000606@gocept.com> <8327C3E8-80E4-450D-B282-43309FDA5061@masklinn.net> <4E770C69.50704@gocept.com> <4E774400.4040905@gocept.com> Message-ID: Christian The wsgi.org domain has reverted back to point to 'DZUG-Sprints' site rather than to www.wsgi.org or wsgi.readthedocs.org. Can you see what it going on. Thanks. Graham On 20 September 2011 07:42, Graham Dumpleton wrote: > Christian. The DNS entry is actually wrong. Got this from Eric: > > ?GrahamDumpleton: wanted to let you know they changed the DNS for wsgi.org, > ?but they pointed it at wsgi.readthedocs.org, so I made this project > in its place > ?so the CNAME would resolve: http://readthedocs.org/projects/wsgi > > ?that isn't yours: http://readthedocs.org/projects/wsgiorg/ > > ?I can either renmae the slug on yours, or you can get them to change the DNS > > Don't change the DNS though as I reckon it may be better that we claim: > > ?wsgi.readthedocs.org > > Will stop someone else claiming generic WSGI for some project. > > Eric, yes, please change the slug. > > Thanks. > > Graham > > On 20 September 2011 06:42, Graham Dumpleton wrote: >> Thanks. >> >> One thing we should do now is create a page with instructions on how >> you can contribute changes back via github project. >> >> Graham >> >> On 19 September 2011 23:30, Christian Theune wrote: >>> Hi, >>> >>> On 09/19/2011 11:33 AM, Christian Theune wrote: >>>> >>>> OK, I updated our database. The nameservers should start propagating >>>> this in an hour or so. >>> >>> After some messing around with CNAMES and such I added a redirect from >>> wsgi.org -> www.wsgi.org and a CNAME of www.wsgi.org to readthedocs. >>> >>> I also added a placeholder page while the DNS updates are in progress >>> including a link to the direct readthedocs.org address. >>> >>> Hope this helps, >>> Christian >>> >>> >>> -- >>> Christian Theune ? ct at gocept.com >>> gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany >>> http://gocept.com ? tel +49 345 1229889 0 ? fax +49 345 1229889 1 >>> Zope and Plone consulting, development, hosting, operations >>> >> From stephan at transvection.de Mon Apr 16 18:09:53 2012 From: stephan at transvection.de (Stephan Diehl) Date: Mon, 16 Apr 2012 18:09:53 +0200 Subject: [Web-SIG] Move www.wsgi.org to Read The Docs In-Reply-To: References: <20110819075141.GA25554@transvection.de> <4E6B31AA.1020403@transvection.de> <41E4CF7F-1F21-42CA-8142-B97ABC6D2AB6@masklinn.net> <4E6BB7FA.4050707@transvection.de> <4E965653-DDD1-4471-9952-84EC9A87C26E@masklinn.net> <4E6BBF51.5050907@transvection.de> <5139BF78-ED40-410F-A361-D0E441451327@masklinn.net> <4E7709A6.4000606@gocept.com> <8327C3E8-80E4-450D-B282-43309FDA5061@masklinn.net> <4E770C69.50704@gocept.com> <4E774400.4040905@gocept.com> Message-ID: <4F8C4451.1030003@transvection.de> Hi Graham, I have contacted support at gocept.com and they have changed (rechanged) the settings. requests to 'wsgi.org'/'www.wsgi.org' will now be forwarded (again) to wsgi.readthedocs.org Cheers, Stephan Am 13.04.2012 02:09, schrieb Graham Dumpleton: > Christian > > The wsgi.org domain has reverted back to point to 'DZUG-Sprints' site > rather than to www.wsgi.org or wsgi.readthedocs.org. > > Can you see what it going on. > > Thanks. > > Graham > > > > On 20 September 2011 07:42, Graham Dumpleton wrote: >> Christian. The DNS entry is actually wrong. Got this from Eric: >> >> GrahamDumpleton: wanted to let you know they changed the DNS for wsgi.org, >> but they pointed it at wsgi.readthedocs.org, so I made this project >> in its place >> so the CNAME would resolve: http://readthedocs.org/projects/wsgi >> >> that isn't yours: http://readthedocs.org/projects/wsgiorg/ >> >> I can either renmae the slug on yours, or you can get them to change the DNS >> >> Don't change the DNS though as I reckon it may be better that we claim: >> >> wsgi.readthedocs.org >> >> Will stop someone else claiming generic WSGI for some project. >> >> Eric, yes, please change the slug. >> >> Thanks. >> >> Graham >> >> On 20 September 2011 06:42, Graham Dumpleton wrote: >>> Thanks. >>> >>> One thing we should do now is create a page with instructions on how >>> you can contribute changes back via github project. >>> >>> Graham >>> >>> On 19 September 2011 23:30, Christian Theune wrote: >>>> Hi, >>>> >>>> On 09/19/2011 11:33 AM, Christian Theune wrote: >>>>> >>>>> OK, I updated our database. The nameservers should start propagating >>>>> this in an hour or so. >>>> >>>> After some messing around with CNAMES and such I added a redirect from >>>> wsgi.org -> www.wsgi.org and a CNAME of www.wsgi.org to readthedocs. >>>> >>>> I also added a placeholder page while the DNS updates are in progress >>>> including a link to the direct readthedocs.org address. >>>> >>>> Hope this helps, >>>> Christian >>>> >>>> >>>> -- >>>> Christian Theune ? ct at gocept.com >>>> gocept gmbh& co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany >>>> http://gocept.com ? tel +49 345 1229889 0 ? fax +49 345 1229889 1 >>>> Zope and Plone consulting, development, hosting, operations >>>> >>>