From ianb at colorstudy.com Sat Jul 7 05:41:49 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 06 Jul 2007 22:41:49 -0500 Subject: [Web-SIG] wsgiconfig design Message-ID: <468F0B7D.9050305@colorstudy.com> Every so often I get in this cleanup/redux mood where I feel a need to revisit things I've done before in an attempt to Do Them Right. We've discussed Paste Deploy here before, and I'm thinking about Redoing It Right. I thought I'd share some thoughts on the design: I still am quite happy with the entry points from Paste Deploy, and plan to keep them, except perhaps paste.composite_factory which I might replace with another way of creating composites that takes a dictionary as an argument (a dictionary of section names to WSGI applications). I will probably rename them, but also support the old Paste Deploy names. The composite entry point isn't too big a deal, because it's mostly just Paste that implements those kinds of components -- normal people just write applications and middleware that dispatches to a single application. There will be a few levels of pluggability. The first is the loader itself, which will default to the wsgiconfig loader itself. This is only applicable to file-based configuration. When you load up the application from a file, it will search for a #! line that specifies a loader, which is the name of a distribution or module. It will search the distribution for some entry point (wsgiconfig.config_loader:main), and that entry point is a callable like: def config_loader(filename, options, object_type): return wsgi_application options is a flat dictionary of options that are passed in, which the config loader can use at its discretion. A common way to use it would be for variable substitution. This allows for things like "paster serve config.ini var1=value var2=value", for ad hoc customization. It returns a single application. (This does mean that a feature from Paste Deploy is lost, where you could do "paster serve config.ini#section_name" to load a specific application from several defined in a file -- but you are less likely to get dead sections or confusing config file factorings). object_type is the kind of object we want to get out. Here I'll only specify 'wsgi.application'. 'wsgi.server' will probably also be implemented, but that's all I plan for now. 'wsgi.appserver' or something might be possible, for the process manager that runs an entire application. From there, you can do whatever. But importantly, wsgiconfig defines a loader which I hope people will like. Unlike Paste Deploy, section names will not be arbitrary. A section name has a prefix and name. The prefix, as in Paste Deploy, says what you are describing. The default prefix is "app:"; you can also give "middleware:". Prefixes not recognized will be ignored. A possible prefix might be "logging:" for logging, which if I don't implement it will be initially ignored (but someone else could handle it). Similarly the server as with Paste Deploy can be defined with "server:". For now all we're concerned with is applications, middleware, and composites. The applications and middleware are grouped together using the names. That is, if you have an application "/" and a middleware "middleware:/", then the middleware wraps that application. Middleware sections can have trailing numbers to indicate ordering and keep section names unique. Thus "middleware:/ 1", "middleware:/ 2", etc. Negative numbers and floats are allowed. Anything but trailing numbers is considered part of the name; thus names can have parameters or other structure. All the applications in the server are put in a single dictionary, and that is based to the composer. The composer by default is urlmap (which also includes optional host-based dispatch). You can specify another composer with a global option "composer = (specifier)" The sections still have a "use" option, which indicates what implements the option. It will take "egg:", and dotted module/object names, and module names may have trailing entry point specifiers (if the object doesn't implement the "preferred" interface for that kind of output). You cannot use "config:" anymore, instead that will be handled by the config file format. The config files will use INITools, which is similar to ConfigParser but a bit nicer. It will include improved string substitution, including similar constructs to what zc.buildout has. While still keeping applications firmly separated from the config files, I'm planning on paying close attention to call signatures and exceptions to give good error messages. E.g., if you raise something like TypeError("... got an unexpected keyword argument 'X'") I'll figure out where the keyword arguments came from and improve the text of that error message. Not perfect, but should be passable, and better than what Paste Deploy does now. That's pretty much it. I won't write any server stuff for now, except maybe try to get "paster serve" to work with these files. I'll try to include a simple framework for applications that want to have their own command-line runners, so that if you have some neat little application you can just tell people to install it and run "serve-applicationname" or whatever you call your script. Anyway, those are my thoughts. I'm going to give it a go this weekend. -- Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers From ianb at colorstudy.com Sat Jul 7 05:55:11 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 06 Jul 2007 22:55:11 -0500 Subject: [Web-SIG] entry points, etc Message-ID: <468F0E9F.2030904@colorstudy.com> Incidentally, something that would be nice with wsgiconfig is if we could all agree on how to specify things like entry points and objects. Specifically Paste Deploy uses egg:Distribution#ep_name, and zc.buildout uses Distribution:ep_name. And Paste Deploy defaults to ep_name=main while zc.buildout defaults to ep_name=default. Paste Deploy uses "entry_point_type = object.name" when you aren't using an entry point, but I'd like to switch to just "object.name" with an optional "object.name [ep_type]". This helps out those people who have some hangup with writing their own setup.py. So having a clear way to distinguish between an object reference and an entry point reference would be ideal. I still would prefer the entry points, as they make it easier to search the system for providing objects and easier to handle backward compatibility, but I don't have any reason to *require* entry points in my code generally. -- Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers From jim at zope.com Sat Jul 7 17:02:50 2007 From: jim at zope.com (Jim Fulton) Date: Sat, 7 Jul 2007 11:02:50 -0400 Subject: [Web-SIG] wsgiconfig design In-Reply-To: <468F0B7D.9050305@colorstudy.com> References: <468F0B7D.9050305@colorstudy.com> Message-ID: <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> On Jul 6, 2007, at 11:41 PM, Ian Bicking wrote: > Every so often I get in this cleanup/redux mood where I feel a need to > revisit things I've done before in an attempt to Do Them Right. > > We've discussed Paste Deploy here before, and I'm thinking about > Redoing > It Right. Cool. > I thought I'd share some thoughts on the design: > > I still am quite happy with the entry points from Paste Deploy, and > plan > to keep them, Me too. In fact, I'd really like them to have their own identity independent if Paste Deploy. People should start supporting these entry points even if they use some other application to put them together. I do have one potential complaint about the entry-point APIs. The applications my company builds have configurations that are too complex to fit in a single config-parser section. To handle these configurations, I'd need to be able to read multiple sections, or to refer to an external configuration. I think the later is the current recommended approach for Paste Deploy. If you want to keep that approach, then the existing entry-point APIs are fine. (I personally, want to be able to put all of my configuration in a single file, but zc.buildout lets me do that, so I don't need Paste Deploy to do that for me.) ... > I will probably rename them, but also support the old Paste Deploy > names. Why? ... > There will be a few levels of pluggability. The first is the loader > itself, which will default to the wsgiconfig loader itself. This is > only applicable to file-based configuration. When you load up the > application from a file, it will search for a #! line that specifies a > loader, which is the name of a distribution or module. It will search > the distribution for some entry point (wsgiconfig.config_loader:main), > and that entry point is a callable like: > > def config_loader(filename, options, object_type): > return wsgi_application which section would it get these from? > options is a flat dictionary of options that are passed in, which the > config loader can use at its discretion. A common way to use it would > be for variable substitution. This allows for things like "paster > serve > config.ini var1=value var2=value", for ad hoc customization. It > returns > a single application. (This does mean that a feature from Paste > Deploy > is lost, where you could do "paster serve config.ini#section_name" to > load a specific application from several defined in a file -- but you > are less likely to get dead sections or confusing config file > factorings). > > object_type is the kind of object we want to get out. Here I'll only > specify 'wsgi.application'. 'wsgi.server' will probably also be > implemented, but that's all I plan for now. 'wsgi.appserver' or > something might be possible, for the process manager that runs an > entire > application. I don't really follow this. Maybe an example would help. ... > Unlike Paste Deploy, section names will not be arbitrary. A section > name has a prefix and name. The prefix, as in Paste Deploy, says what > you are describing. The default prefix is "app:"; you can also give > "middleware:". Prefixes not recognized will be ignored. A possible > prefix might be "logging:" for logging, which if I don't implement it > will be initially ignored (but someone else could handle it). IMO, it would be nice *not* to reinvent yet another logging configuration handler. The standard library already defines one. If we don't like it, we should make it better. > Similarly > the server as with Paste Deploy can be defined with "server:". For > now > all we're concerned with is applications, middleware, and composites. Maybe I'm missing your point, but I thought the value of Paste Deploy was to be able to have a way to define and end-to-end configuration of applications, middleware and server. > The applications and middleware are grouped together using the names. > That is, if you have an application "/" and a middleware > "middleware:/", > then the middleware wraps that application. Middleware sections can > have trailing numbers to indicate ordering and keep section names > unique. Thus "middleware:/ 1", "middleware:/ 2", etc. Negative > numbers > and floats are allowed. Anything but trailing numbers is considered > part of the name; thus names can have parameters or other structure. Hm. Sounds a bit too magic to me. Maybe an example will make it look better. :) > All the applications in the server are put in a single dictionary, and > that is based to the composer. The composer by default is urlmap > (which > also includes optional host-based dispatch). You can specify another > composer with a global option "composer = (specifier)" I'm not sure how I feel about that. > The sections still have a "use" option, which indicates what > implements > the option. It will take "egg:", and dotted module/object names, and > module names may have trailing entry point specifiers (if the object > doesn't implement the "preferred" interface for that kind of output). > You cannot use "config:" anymore, instead that will be handled by the > config file format. Good. I found this dual use of "use" to be confusing. > The config files will use INITools, which is similar to > ConfigParser but > a bit nicer. It will include improved string substitution, including > similar constructs to what zc.buildout has. While still keeping > applications firmly separated from the config files, I'm planning on > paying close attention to call signatures and exceptions to give good > error messages. E.g., if you raise something like TypeError("... > got an > unexpected keyword argument 'X'") I'll figure out where the keyword > arguments came from and improve the text of that error message. Not > perfect, but should be passable, and better than what Paste Deploy > does now. One suggestion to improve error detection/warning is to use RawConfigParse rather than ConfigParse and to track option access. A common mistake when writing configurations is to misspell something. You end up with options that are ignored because they are misspelled. This sort of error can be hard to spot. Handlers could complain about unused options, but this is hard to do if a DEFAULT sections causes options to appear in all sections. Also, expecting handlers to do this sort of error checking is a bit if a burden on handler writers. This may not be such a problem for Paste Deploy handlers as a is for buildout recipes. In buildout, I decided to shift this error checking to buildout itself. Buildout tracks option access and warns about unused options. This can be very helpful and puts no burden on recipe writers. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From jim at zope.com Sat Jul 7 17:15:12 2007 From: jim at zope.com (Jim Fulton) Date: Sat, 7 Jul 2007 11:15:12 -0400 Subject: [Web-SIG] entry points, etc In-Reply-To: <468F0E9F.2030904@colorstudy.com> References: <468F0E9F.2030904@colorstudy.com> Message-ID: <346386E9-FB03-4713-BCFB-35E95EC8DD99@zope.com> On Jul 6, 2007, at 11:55 PM, Ian Bicking wrote: > Incidentally, something that would be nice with wsgiconfig is if we > could all agree on how to specify things like entry points and > objects. > Specifically Paste Deploy uses egg:Distribution#ep_name, and > zc.buildout uses Distribution:ep_name. And Paste Deploy defaults to > ep_name=main while zc.buildout defaults to ep_name=default. Yup. Some notes. # is unattractive to me because it looks like a comment. ConfigParser is a bit odd in it's treatment of #s. It treates them as comments after empty lines and after section names, but not after comments. I used ":" because setuptools uses module:name when defining entry points. That may not have been a good reason. If we agree on some standard, I'll support it. That should happen over on the distutils-sig list. > Paste Deploy uses "entry_point_type = object.name" when you aren't > using > an entry point, but I'd like to switch to just "object.name" with an > optional "object.name [ep_type]". This helps out those people who > have > some hangup with writing their own setup.py. So having a clear way to > distinguish between an object reference and an entry point reference > would be ideal. I still would prefer the entry points, as they > make it > easier to search the system for providing objects and easier to handle > backward compatibility, but I don't have any reason to *require* entry > points in my code generally. It is hard to assess this out of context. I will note that setuptools uses dotted_module_name:dotted_object_name to name objects and I'd be inclined to be consistent with that. If we used a different delimiter between eggs and entry points and between modules and names, then we'd be able to tell the refrecnes apart. Again, I think this is more general than web applications. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From ianb at colorstudy.com Sat Jul 7 21:01:03 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 07 Jul 2007 14:01:03 -0500 Subject: [Web-SIG] wsgiconfig design In-Reply-To: <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> Message-ID: <468FE2EF.8080100@colorstudy.com> Jim Fulton wrote: > > On Jul 6, 2007, at 11:41 PM, Ian Bicking wrote: > >> Every so often I get in this cleanup/redux mood where I feel a need to >> revisit things I've done before in an attempt to Do Them Right. >> >> We've discussed Paste Deploy here before, and I'm thinking about Redoing >> It Right. > > Cool. > >> I thought I'd share some thoughts on the design: >> >> I still am quite happy with the entry points from Paste Deploy, and plan >> to keep them, > > Me too. In fact, I'd really like them to have their own identity > independent if Paste Deploy. People should start supporting these entry > points even if they use some other application to put them together. I've tried to encourage people to use this, but they get stuck on the word "paste", so there's not many other people who consume or produce these entry points except for use with Paste or related packages (Pylons, etc). I'm not sure what to do about that, except perhaps to reset people's opinions with this rewrite. > I do have one potential complaint about the entry-point APIs. The > applications my company builds have configurations that are too complex > to fit in a single config-parser section. To handle these > configurations, I'd need to be able to read multiple sections, or to > refer to an external configuration. I think the later is the current > recommended approach for Paste Deploy. If you want to keep that > approach, then the existing entry-point APIs are fine. (I personally, > want to be able to put all of my configuration in a single file, but > zc.buildout lets me do that, so I don't need Paste Deploy to do that for > me.) As I've been coding, I've actually been thinking about passing a complete config dictionary in instead of global_conf. So it would be like {section: {option: value, ...}}. This lets you look into other application's sections, which maybe isn't ideal. Another option that occurs to me now might be something like [config:app_name section_name], and then pass in section_name={dict of options} as a keyword argument. I.e.: [/] use = egg:MyPackage greeting = Hello [config:/ email] smtp_server = localhost email = bob at example.com That leads to mypackage.wsgi_app(global_conf, greeting="Hello", email={'smtp_server': 'localhost', 'email': 'bob at example.com}) I think I prefer the latter. >> I will probably rename them, but also support the old Paste Deploy >> names. > > Why? Why rename? To go with the new package, and because I might change the entry points slightly (particularly global_conf or those extra config sections). I'd support the old names because I can, even if they are somewhat different APIs; a nice side effect of explicit entry point groups. >> There will be a few levels of pluggability. The first is the loader >> itself, which will default to the wsgiconfig loader itself. This is >> only applicable to file-based configuration. When you load up the >> application from a file, it will search for a #! line that specifies a >> loader, which is the name of a distribution or module. It will search >> the distribution for some entry point (wsgiconfig.config_loader:main), >> and that entry point is a callable like: >> >> def config_loader(filename, options, object_type): >> return wsgi_application > > which section would it get these from? Which entry point group? The group is [wsgiconfig.config_loader]. The loader's name is taken from the #! line, so you don't have to use ini format at all if you don't want to. This is to placate people who really hate that format ;) >> options is a flat dictionary of options that are passed in, which the >> config loader can use at its discretion. A common way to use it would >> be for variable substitution. This allows for things like "paster serve >> config.ini var1=value var2=value", for ad hoc customization. It returns >> a single application. (This does mean that a feature from Paste Deploy >> is lost, where you could do "paster serve config.ini#section_name" to >> load a specific application from several defined in a file -- but you >> are less likely to get dead sections or confusing config file >> factorings). >> >> object_type is the kind of object we want to get out. Here I'll only >> specify 'wsgi.application'. 'wsgi.server' will probably also be >> implemented, but that's all I plan for now. 'wsgi.appserver' or >> something might be possible, for the process manager that runs an entire >> application. > > I don't really follow this. Maybe an example would help. Well, lets say you have a configuration like: [/] use = egg:MyApp [middleware:/] use = egg:Paste#profile [server:main] # or maybe just server? use = egg:Paste#http host = 127.0.0.1:${port} Then you start it up with "serve config.ini port=8090". That's the idea of the options dictionary, it holds {'port': '8090'}. When you load the config file, all the applications defined in the config are collected and combined, by default using urlmap. There's only one in this example, '/'. So what gets returned is basically: URLMap({'/': profile_middleware(MyApp_app(global_conf), global_conf)}) >> Unlike Paste Deploy, section names will not be arbitrary. A section >> name has a prefix and name. The prefix, as in Paste Deploy, says what >> you are describing. The default prefix is "app:"; you can also give >> "middleware:". Prefixes not recognized will be ignored. A possible >> prefix might be "logging:" for logging, which if I don't implement it >> will be initially ignored (but someone else could handle it). > > IMO, it would be nice *not* to reinvent yet another logging > configuration handler. The standard library already defines one. If we > don't like it, we should make it better. I don't like it, but I don't feel like improving it either ;) Anyway, this is basically just a convention to group all the sections together for logging based on that prefix. The logging module's configuration handler can handle it, or we could wrap it slightly (if you loaded logging you wouldn't actually be returning anything, you'd be updating the global logging configuration, which may or may not be what we want). >> Similarly >> the server as with Paste Deploy can be defined with "server:". For now >> all we're concerned with is applications, middleware, and composites. > > Maybe I'm missing your point, but I thought the value of Paste Deploy > was to be able to have a way to define and end-to-end configuration of > applications, middleware and server. The server is a little bit of an outlier. The applications and middleware can be composed directly and fairly opaquely, but the server needs to be connected to the application more explicitly and outside of wsgiconfig. OTOH, it's real handy to be able to put the server section in the same config file. >> The applications and middleware are grouped together using the names. >> That is, if you have an application "/" and a middleware "middleware:/", >> then the middleware wraps that application. Middleware sections can >> have trailing numbers to indicate ordering and keep section names >> unique. Thus "middleware:/ 1", "middleware:/ 2", etc. Negative numbers >> and floats are allowed. Anything but trailing numbers is considered >> part of the name; thus names can have parameters or other structure. > > Hm. Sounds a bit too magic to me. Maybe an example will make it look > better. :) Well, what we are trying to create is a basic middleware1(middleware2(app)) composition, where the app is required and the middleware is not. We group these together by name, with urlmap that name is a path. So / is the main app, /blog is the app mounted at /blog, etc. Then we need an ordered list of the middleware to apply. There needs to be some way to distinguish a middleware section from an application section, hence middleware:. And then a way of ordering them. We could use the section ordering, except duplicate section names are no good anyway, even if we did keep track of the order they were defined in. So I'm proposing a trailing number. The rest of the name is significant. For instance, a composer might take a section name like [/ domain=foo.com], and use that entire section name to determine that it's mapped to a specific vhost. The middleware would have to use exactly that same name, [middleware:/ domain=foo.com]. >> All the applications in the server are put in a single dictionary, and >> that is based to the composer. The composer by default is urlmap (which >> also includes optional host-based dispatch). You can specify another >> composer with a global option "composer = (specifier)" > > I'm not sure how I feel about that. What would be the problem? >> The sections still have a "use" option, which indicates what implements >> the option. It will take "egg:", and dotted module/object names, and >> module names may have trailing entry point specifiers (if the object >> doesn't implement the "preferred" interface for that kind of output). >> You cannot use "config:" anymore, instead that will be handled by the >> config file format. > > Good. I found this dual use of "use" to be confusing. Actually I realize there has to be something like this, but probably simpler. That is, you have to be able to say, "for this application, get the application from this other file". That could simply be: [/blog] use = egg:WSGIConfig#load_config config_file = blog.ini But that's kind of awkward, so I think it would be better if there was a clearer construct. blog.ini might itself have internal structure and multiple applications, so we can't just use config file inlining to accomplish this. >> The config files will use INITools, which is similar to ConfigParser but >> a bit nicer. It will include improved string substitution, including >> similar constructs to what zc.buildout has. While still keeping >> applications firmly separated from the config files, I'm planning on >> paying close attention to call signatures and exceptions to give good >> error messages. E.g., if you raise something like TypeError("... got an >> unexpected keyword argument 'X'") I'll figure out where the keyword >> arguments came from and improve the text of that error message. Not >> perfect, but should be passable, and better than what Paste Deploy >> does now. > > One suggestion to improve error detection/warning is to use > RawConfigParse rather than ConfigParse and to track option access. A > common mistake when writing configurations is to misspell something. > You end up with options that are ignored because they are misspelled. > This sort of error can be hard to spot. Handlers could complain about > unused options, but this is hard to do if a DEFAULT sections causes > options to appear in all sections. Also, expecting handlers to do this > sort of error checking is a bit if a burden on handler writers. This may > not be such a problem for Paste Deploy handlers as a is for buildout > recipes. In buildout, I decided to shift this error checking to > buildout itself. Buildout tracks option access and warns about unused > options. This can be very helpful and puts no burden on recipe writers. The config files in this model entirely push out information, no one goes fishing into the config file. So there's no way to determine access. If you are restrictive in your entry point and don't include **kw, then you can raise errors about misspelled configuration. This isn't true in global_conf, and I suppose I could track that, but tracking a dictionary around into Python code makes me a little uncomfortable. It can be a real problem when I can't remember whether the error email setting (which is typically inherited through global_conf) is error_email or email_errors. I am thinking about adding some kind of logging to all of this, so it's easy both to get an explanation of what exactly is being constructed, and to get a detailed report when something goes wrong. -- Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers From ianb at colorstudy.com Sat Jul 7 21:12:11 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 07 Jul 2007 14:12:11 -0500 Subject: [Web-SIG] entry points, etc In-Reply-To: <346386E9-FB03-4713-BCFB-35E95EC8DD99@zope.com> References: <468F0E9F.2030904@colorstudy.com> <346386E9-FB03-4713-BCFB-35E95EC8DD99@zope.com> Message-ID: <468FE58B.7070309@colorstudy.com> Jim Fulton wrote: > > On Jul 6, 2007, at 11:55 PM, Ian Bicking wrote: > >> Incidentally, something that would be nice with wsgiconfig is if we >> could all agree on how to specify things like entry points and objects. >> Specifically Paste Deploy uses egg:Distribution#ep_name, and >> zc.buildout uses Distribution:ep_name. And Paste Deploy defaults to >> ep_name=main while zc.buildout defaults to ep_name=default. > > Yup. > > Some notes. # is unattractive to me because it looks like a comment. > ConfigParser is a bit odd in it's treatment of #s. It treates them as > comments after empty lines and after section names, but not after comments. If ConfigParser did pay attention to comments it would make everything much more complicated. But that's another issue. > I used ":" because setuptools uses module:name when defining entry > points. That may not have been a good reason. Well, it could be good or bad overlap. Mostly it has to be something illegal in a distribution name, and ideally in any specifier (so you can do Package==0.5:ep_name). > If we agree on some standard, I'll support it. That should happen over > on the distutils-sig list. OK, copied over. >> Paste Deploy uses "entry_point_type = object.name" when you aren't using >> an entry point, but I'd like to switch to just "object.name" with an >> optional "object.name [ep_type]". This helps out those people who have >> some hangup with writing their own setup.py. So having a clear way to >> distinguish between an object reference and an entry point reference >> would be ideal. I still would prefer the entry points, as they make it >> easier to search the system for providing objects and easier to handle >> backward compatibility, but I don't have any reason to *require* entry >> points in my code generally. > > It is hard to assess this out of context. I will note that setuptools > uses dotted_module_name:dotted_object_name to name objects and I'd be > inclined to be consistent with that. If we used a different delimiter > between eggs and entry points and between modules and names, then we'd > be able to tell the refrecnes apart. Again, I think this is more > general than web applications. Another case came up as I was thinking about this, which is referring to an object in a specific Python file (not module). I find this very useful when I'm doing some kind of configuration that involves deployment-specific code. I really don't want to create a package and module and fiddle with sys.path, for a bit of code that is purely deployment specific. So I'd like to also allow for a specifier like filename:object_name. We could use prefixes for all of these. I'm fine supporting : instead of # for entry point names. We could use prefixes, e.g., "egg:Package:ep". Somehow that reads a little funny to me, too many colons. We could also just use "egg Package:ep", which maybe reads better. Then there'd also be "python module:object", and "file filename.py:object". Maybe "python " would be the default, I'm not sure. I encourage people to use entry points, but I don't mind including "egg " -- if anything, I think the name is helpful to people who aren't always clear on the distinction between distributions and packages and modules. The default entry point name is also important. I prefer "main" because I think it better describes the purpose of the entry-point-that-need-not-be-named. "default" feels like it's just describing the mechanism of the entry point loader. -- Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers From fdrake at gmail.com Sat Jul 7 21:41:39 2007 From: fdrake at gmail.com (Fred Drake) Date: Sat, 7 Jul 2007 15:41:39 -0400 Subject: [Web-SIG] entry points, etc In-Reply-To: <468FE58B.7070309@colorstudy.com> References: <468F0E9F.2030904@colorstudy.com> <346386E9-FB03-4713-BCFB-35E95EC8DD99@zope.com> <468FE58B.7070309@colorstudy.com> Message-ID: <9cee7ab80707071241k2f4c2fb6u9cefe9e5980a27b9@mail.gmail.com> On 7/7/07, Ian Bicking wrote: > Then there'd also be "python module:object", and "file > filename.py:object". Maybe "python " would be the default, I'm not > sure. I'd be in favor of not having a default expression type for this, but to require it to be spelled out every time. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From jim at zope.com Sun Jul 8 13:31:05 2007 From: jim at zope.com (Jim Fulton) Date: Sun, 8 Jul 2007 07:31:05 -0400 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: <468FE2EF.8080100@colorstudy.com> References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: On Jul 7, 2007, at 3:01 PM, Ian Bicking wrote: > Jim Fulton wrote: >> On Jul 6, 2007, at 11:41 PM, Ian Bicking wrote: >>> Every so often I get in this cleanup/redux mood where I feel a >>> need to >>> revisit things I've done before in an attempt to Do Them Right. >>> >>> We've discussed Paste Deploy here before, and I'm thinking about >>> Redoing >>> It Right. >> Cool. >>> I thought I'd share some thoughts on the design: >>> >>> I still am quite happy with the entry points from Paste Deploy, >>> and plan >>> to keep them, >> Me too. In fact, I'd really like them to have their own identity >> independent if Paste Deploy. People should start supporting these >> entry points even if they use some other application to put them >> together. > > I've tried to encourage people to use this, but they get stuck on the > word "paste", so there's not many other people who consume or produce > these entry points except for use with Paste or related packages > (Pylons, etc). I'm not sure what to do about that, except perhaps to > reset people's opinions with this rewrite. Well, this touches a nerve with me. I have a similar problem with people rejecting out of hand anything that happens to live in the zope or even the zc namespace. Similarly, at PyCon, I try to always give at least talk that I think will be generally interesting to the Python community at large, yet many people tend to assume that these are Zope specific. I think this behavior is extremely unhealthy for the Python community. Paste deploy is the only effort I've seen to provided a much-needed glue layer for WSGI. It doesn't matter one bit to me what it's called. It tries to fill a basic need. Now I'm all for competition. If someone really wanted to come up with something better, then I wouldn't mind seeing someone try, but nothing else is happening AFAICT. I certainly have other things I want to work on. Paste Deploy is a really good start and, FWIW, the Zope community is embracing it. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From guido at python.org Sun Jul 8 13:48:27 2007 From: guido at python.org (Guido van Rossum) Date: Sun, 8 Jul 2007 13:48:27 +0200 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: On 7/8/07, Jim Fulton wrote: [quoting Ian Bicking] > > I've tried to encourage people to use this, but they get stuck on the > > word "paste", so there's not many other people who consume or produce > > these entry points except for use with Paste or related packages > > (Pylons, etc). I'm not sure what to do about that, except perhaps to > > reset people's opinions with this rewrite. > > Well, this touches a nerve with me. I have a similar problem with > people rejecting out of hand anything that happens to live in the > zope or even the zc namespace. Similarly, at PyCon, I try to always > give at least talk that I think will be generally interesting to the > Python community at large, yet many people tend to assume that these > are Zope specific. I think this behavior is extremely unhealthy for > the Python community. Paste deploy is the only effort I've seen to > provided a much-needed glue layer for WSGI. It doesn't matter one > bit to me what it's called. It tries to fill a basic need. Now I'm > all for competition. If someone really wanted to come up with > something better, then I wouldn't mind seeing someone try, but > nothing else is happening AFAICT. I certainly have other things I > want to work on. Paste Deploy is a really good start and, FWIW, the > Zope community is embracing it. I don't understand why your talks are assumed to be uninteresting to non-Zope-users (how much evidence do you have?), but I have a feeling that the "branding" of generally useful functionality with a particular framework's name is just bad politics. I agree that it's unhealthy for that functionality to be ignored, but the solution is not to complain about people's behavior (that's rarely going to change the behavior being deplored) but to become sensitive to the problem that the brand *apparently* causes and switch to a different brand. Some brands have this problem more than others; I would expect that Marc Andre Lemburg's MX brand doesn't suffer much because it's being marketed as a loosely connected collection of various independently usable subpackages. However the Zope brand is very strongly associated with the web application framework of that name. This is by design, I assume -- check out the snippet for the first Google hit for "Zope". Paste (despite its Google snippet) historically seems to fall in the same category and it may be tough to undo this; moving the install functionality to a separate brand name might be easier (as Ian observed). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From jim at zope.com Sun Jul 8 14:10:27 2007 From: jim at zope.com (Jim Fulton) Date: Sun, 8 Jul 2007 08:10:27 -0400 Subject: [Web-SIG] wsgiconfig design In-Reply-To: <468FE2EF.8080100@colorstudy.com> References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: On Jul 7, 2007, at 3:01 PM, Ian Bicking wrote: > Jim Fulton wrote: .. >> I do have one potential complaint about the entry-point APIs. The >> applications my company builds have configurations that are too >> complex to fit in a single config-parser section. To handle these >> configurations, I'd need to be able to read multiple sections, or >> to refer to an external configuration. I think the later is the >> current recommended approach for Paste Deploy. If you want to >> keep that approach, then the existing entry-point APIs are fine. >> (I personally, want to be able to put all of my configuration in a >> single file, but zc.buildout lets me do that, so I don't need >> Paste Deploy to do that for me.) > > As I've been coding, I've actually been thinking about passing a > complete config dictionary in instead of global_conf. So it would be > like {section: {option: value, ...}}. BTW, I've become a big fan of the ConfigParser module and format, mainly because of it's simplicity. The simplicity of a dictionary of dictionaries is very powerful, IMO. Of course, the ConfigParser API is pretty horrible. Fortunately, it's trivial to convert a parser object to a mapping of mappings and that's generally one of the first things I do after I've parsed a file. > This lets you look into other > application's sections, which maybe isn't ideal. Why? Are you afraid that a handler will look at something it shouldn't? Who cares? Relax. This isn't the Spanish Inquisition. :) Embrace the simplicity of a mapping of mappings. > Another option that occurs to me now might be something like > [config:app_name section_name], and then pass in section_name={dict of > options} as a keyword argument. I.e.: > > [/] > use = egg:MyPackage > greeting = Hello > > [config:/ email] > smtp_server = localhost > email = bob at example.com > > That leads to mypackage.wsgi_app(global_conf, greeting="Hello", > email={'smtp_server': 'localhost', 'email': 'bob at example.com}) > > I think I prefer the latter. I prefer the simpler model. For one thing, it lets you share data among multiple sections. Maybe this isn't important for Paste Deploy. Having said that, I think your suggested is fine and is also less verbose than the simpler approach, because, in the simpler approach, the root section will tend to have options saying what other sections to read. If you are going to do something like this, then, IMO, you might also consider: [/] use = egg:MyPackage greeting = Hello email = smtp_server = localhost email = bob at example.com > >>> I will probably rename them, but also support the old Paste >>> Deploy names. >> Why? > > Why rename? To go with the new package, and because I might change > the > entry points slightly (particularly global_conf or those extra config > sections). I'd support the old names because I can, even if they are > somewhat different APIs; a nice side effect of explicit entry point > groups. Well, if you change the APIs, you pretty much have to rename them. But I wouldn't do it otherwise. Of course, it's up to you. >>> There will be a few levels of pluggability. The first is the loader >>> itself, which will default to the wsgiconfig loader itself. This is >>> only applicable to file-based configuration. When you load up the >>> application from a file, it will search for a #! line that >>> specifies a >>> loader, which is the name of a distribution or module. It will >>> search >>> the distribution for some entry point >>> (wsgiconfig.config_loader:main), >>> and that entry point is a callable like: >>> >>> def config_loader(filename, options, object_type): >>> return wsgi_application >> which section would it get these from? > > Which entry point group? I'm sorry, I was unclear. I meant to ask section will the options came from. You answered that below. ... >>> options is a flat dictionary of options that are passed in, which >>> the >>> config loader can use at its discretion. A common way to use it >>> would >>> be for variable substitution. This allows for things like >>> "paster serve >>> config.ini var1=value var2=value", for ad hoc customization. It >>> returns >>> a single application. (This does mean that a feature from Paste >>> Deploy >>> is lost, where you could do "paster serve >>> config.ini#section_name" to >>> load a specific application from several defined in a file -- but >>> you >>> are less likely to get dead sections or confusing config file >>> factorings). >>> >>> object_type is the kind of object we want to get out. Here I'll >>> only >>> specify 'wsgi.application'. 'wsgi.server' will probably also be >>> implemented, but that's all I plan for now. 'wsgi.appserver' or >>> something might be possible, for the process manager that runs an >>> entire >>> application. >> I don't really follow this. Maybe an example would help. > > Well, lets say you have a configuration like: > > [/] > use = egg:MyApp > > [middleware:/] > use = egg:Paste#profile > > [server:main] # or maybe just server? > use = egg:Paste#http > host = 127.0.0.1:${port} > > Then you start it up with "serve config.ini port=8090". That's the > idea > of the options dictionary, it holds {'port': '8090'}. Ah, so command-line options. In the example, a port is something you'd want to make available in a server section isn't it? Why do you want the loader to get command- line options? ... >>> Unlike Paste Deploy, section names will not be arbitrary. A section >>> name has a prefix and name. The prefix, as in Paste Deploy, says >>> what >>> you are describing. The default prefix is "app:"; you can also give >>> "middleware:". Prefixes not recognized will be ignored. A possible >>> prefix might be "logging:" for logging, which if I don't >>> implement it >>> will be initially ignored (but someone else could handle it). >> IMO, it would be nice *not* to reinvent yet another logging >> configuration handler. The standard library already defines one. >> If we don't like it, we should make it better. > > I don't like it, but I don't feel like improving it either ;) I hope you don't consider that a reason to reinvent it. I would hope that, in the future, when someone gets that itch, they'll resist and improve the standard one instead. We invented ZConfig which has it's own logging configuration "schema". The result? It hasn't remained up to date with the logging package and people who use it don't have access to some useful loggers without screwing with ZConfig schemas (which isn't fun), Bad bad bad. > Anyway, > this is basically just a convention to group all the sections together > for logging based on that prefix. The logging module's configuration > handler can handle it, It can? I think it looks for specific un-prefixed section names. > or we could wrap it slightly (if you loaded > logging you wouldn't actually be returning anything, you'd be updating > the global logging configuration, which may or may not be what we > want). I'm not sure what you mean here. In theory, if you simply let people use the sections defined by the logging module, you could point the standard logging module at your config and be done. You could even condition this on whether the defined sections are present. Unfortunately, I don't speak from experience because the applications I routinely use use ZConfig. > >>> Similarly >>> the server as with Paste Deploy can be defined with "server:". >>> For now >>> all we're concerned with is applications, middleware, and >>> composites. >> Maybe I'm missing your point, but I thought the value of Paste >> Deploy was to be able to have a way to define and end-to-end >> configuration of applications, middleware and server. > > The server is a little bit of an outlier. The applications and > middleware can be composed directly and fairly opaquely, but the > server needs to be connected to the application more explicitly and > outside of wsgiconfig. OTOH, it's real handy to be able to put the > server section in the same config file. IMO, it's very important to put the server in the config. Why make the program using the config do that? I really want to to be able to at least do all of the WSGI configuration in one place. Note that, traditionally, Zope has allowed multiple servers to exist in a single process. For smaller applications that can be handled by a single process, this is a significant win. Selfishly, this isn't so important to me as the applications ZC deals with are large scale and have many processes so having a single server per process is the norm for us. Others may perceive the loss though, >>> The applications and middleware are grouped together using the >>> names. >>> That is, if you have an application "/" and a middleware >>> "middleware:/", >>> then the middleware wraps that application. Middleware sections can >>> have trailing numbers to indicate ordering and keep section names >>> unique. Thus "middleware:/ 1", "middleware:/ 2", etc. Negative >>> numbers >>> and floats are allowed. Anything but trailing numbers is considered >>> part of the name; thus names can have parameters or other structure. >> Hm. Sounds a bit too magic to me. Maybe an example will make it >> look better. :) > > Well, what we are trying to create is a basic middleware1 > (middleware2(app)) composition, where the app is required and the > middleware is not. > > We group these together by name, with urlmap that name is a path. > So / is the main app, /blog is the app mounted at /blog, etc. Then > we need an ordered list of the middleware to apply. There needs to > be some way to distinguish a middleware section from an application > section, hence middleware:. And then a way of ordering them. We > could use the section ordering, except duplicate section names are > no good anyway, even if we did keep track of the order they were > defined in. So I'm proposing a trailing number. Personally, I much prefer explicit composition sections, as I think you have no. Then you simply have an option that names the nodes to be composed in order. ... >>> All the applications in the server are put in a single >>> dictionary, and >>> that is based to the composer. The composer by default is urlmap >>> (which >>> also includes optional host-based dispatch). You can specify >>> another >>> composer with a global option "composer = (specifier)" >> I'm not sure how I feel about that. > > What would be the problem? I'd prefer the composers be more explicitly part of the configuration. That is, a composer is defined with a section, like everything else. >>> The sections still have a "use" option, which indicates what >>> implements >>> the option. It will take "egg:", and dotted module/object names, >>> and >>> module names may have trailing entry point specifiers (if the object >>> doesn't implement the "preferred" interface for that kind of >>> output). >>> You cannot use "config:" anymore, instead that will be handled by >>> the >>> config file format. >> Good. I found this dual use of "use" to be confusing. > > Actually I realize there has to be something like this, but > probably simpler. Sure. > That is, you have to be able to say, "for this application, get > the application from this other file". That could simply be: > > [/blog] > use = egg:WSGIConfig#load_config > config_file = blog.ini > > But that's kind of awkward, so I think it would be better if there > was a clearer construct. blog.ini might itself have internal > structure and multiple applications, so we can't just use config > file inlining to accomplish this. I mainly think this is a different concept and should have a separate option name, whatever syntax is used. >>> The config files will use INITools, which is similar to >>> ConfigParser but >>> a bit nicer. It will include improved string substitution, >>> including >>> similar constructs to what zc.buildout has. While still keeping >>> applications firmly separated from the config files, I'm planning on >>> paying close attention to call signatures and exceptions to give >>> good >>> error messages. E.g., if you raise something like TypeError("... >>> got an >>> unexpected keyword argument 'X'") I'll figure out where the keyword >>> arguments came from and improve the text of that error message. Not >>> perfect, but should be passable, and better than what Paste >>> Deploy does now. >> One suggestion to improve error detection/warning is to use >> RawConfigParse rather than ConfigParse and to track option >> access. A common mistake when writing configurations is to >> misspell something. You end up with options that are ignored >> because they are misspelled. This sort of error can be hard to >> spot. Handlers could complain about unused options, but this is >> hard to do if a DEFAULT sections causes options to appear in all >> sections. Also, expecting handlers to do this sort of error >> checking is a bit if a burden on handler writers. This may not be >> such a problem for Paste Deploy handlers as a is for buildout >> recipes. In buildout, I decided to shift this error checking to >> buildout itself. Buildout tracks option access and warns about >> unused options. This can be very helpful and puts no burden on >> recipe writers. > > The config files in this model entirely push out information, no > one goes fishing into the config file. So there's no way to > determine access. > > If you are restrictive in your entry point and don't include **kw, > then you can raise errors about misspelled configuration. Sure, but don't options put in DEFAULT appear everywhere? Won't that make it impossible to avoid **kw and to complain about unrecognized options? > This isn't true in global_conf, and I suppose I could track that, > but tracking a dictionary around into Python code makes me a little > uncomfortable. It can be a real problem when I can't remember > whether the error email setting (which is typically inherited > through global_conf) is error_email or email_errors. It's OK to make handlers do error checking, but, unless I'm missing something, DEFAULT works against error checking no matter where it's done. > I am thinking about adding some kind of logging to all of this, so > it's easy both to get an explanation of what exactly is being > constructed, and to get a detailed report when something goes wrong. Logging is good. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From jim at zope.com Sun Jul 8 14:31:16 2007 From: jim at zope.com (Jim Fulton) Date: Sun, 8 Jul 2007 08:31:16 -0400 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: On Jul 8, 2007, at 7:48 AM, Guido van Rossum wrote: > On 7/8/07, Jim Fulton wrote: ... > I don't understand why your talks are assumed to be uninteresting to > non-Zope-users (how much evidence do you have? A fair bit. I've had people tell me, "Oh, I'm not going to that, it's a Zope talk." Also, based on who's in the audience. This isn't always the case, but it is too often IMO. > ), but I have a feeling > that the "branding" of generally useful functionality with a > particular framework's name is just bad politics. I agree that it's > unhealthy for that functionality to be ignored, but the solution is > not to complain about people's behavior (that's rarely going to change > the behavior being deplored) but to become sensitive to the problem > that the brand *apparently* causes and switch to a different brand. Your point is well taken wrt the zope name. I find this phenomena applies to "zc" as well. I use the zc namespace so that my package names can be descriptive without creating annoying name conflicts. Is "zc" a brand? It seems reasonable that namespace package names should reflect organization names. If that makes them too brand- laden, then how should people pick namespace names? Should we pick random letters? Should I use namespaces like "python", "web", or maybe "nice"? ;) Aside from the more general issue, in the context of web software, I hope we can reuse each others components without having to rename everything. What a waste of time that would be. Does this have to be so political? Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From renesd at gmail.com Sun Jul 8 16:11:11 2007 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 9 Jul 2007 00:11:11 +1000 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: <64ddb72c0707080711i56b4f796sa44ad7cf243f9e41@mail.gmail.com> I think the reason is that zope, and paste are not named for what they do. I mean, without knowing what's in them, zope and paste are kind of abstract things for people. I mean if something was called zope.configurator vs configurator - people might think the zope one is zope specific. That it's for zope, or used with zope. Putting all the zope bits separately in the cheeseshop makes it more obvious that they can be used separately. But I still keep thinking they are zope specific things - even though I know they can be used separately. Same for paste. That is my thinking anyway - maybe other people think that way too. On 7/8/07, Jim Fulton wrote: > > On Jul 7, 2007, at 3:01 PM, Ian Bicking wrote: > > > Jim Fulton wrote: > >> On Jul 6, 2007, at 11:41 PM, Ian Bicking wrote: > >>> Every so often I get in this cleanup/redux mood where I feel a > >>> need to > >>> revisit things I've done before in an attempt to Do Them Right. > >>> > >>> We've discussed Paste Deploy here before, and I'm thinking about > >>> Redoing > >>> It Right. > >> Cool. > >>> I thought I'd share some thoughts on the design: > >>> > >>> I still am quite happy with the entry points from Paste Deploy, > >>> and plan > >>> to keep them, > >> Me too. In fact, I'd really like them to have their own identity > >> independent if Paste Deploy. People should start supporting these > >> entry points even if they use some other application to put them > >> together. > > > > I've tried to encourage people to use this, but they get stuck on the > > word "paste", so there's not many other people who consume or produce > > these entry points except for use with Paste or related packages > > (Pylons, etc). I'm not sure what to do about that, except perhaps to > > reset people's opinions with this rewrite. > > Well, this touches a nerve with me. I have a similar problem with > people rejecting out of hand anything that happens to live in the > zope or even the zc namespace. Similarly, at PyCon, I try to always > give at least talk that I think will be generally interesting to the > Python community at large, yet many people tend to assume that these > are Zope specific. I think this behavior is extremely unhealthy for > the Python community. Paste deploy is the only effort I've seen to > provided a much-needed glue layer for WSGI. It doesn't matter one > bit to me what it's called. It tries to fill a basic need. Now I'm > all for competition. If someone really wanted to come up with > something better, then I wouldn't mind seeing someone try, but > nothing else is happening AFAICT. I certainly have other things I > want to work on. Paste Deploy is a really good start and, FWIW, the > Zope community is embracing it. > > Jim > > -- > Jim Fulton mailto:jim at zope.com Python Powered! > CTO (540) 361-1714 http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org > > > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/renesd%40gmail.com > From ct at gocept.com Sun Jul 8 16:19:53 2007 From: ct at gocept.com (Christian Theune) Date: Sun, 08 Jul 2007 16:19:53 +0200 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: <64ddb72c0707080711i56b4f796sa44ad7cf243f9e41@mail.gmail.com> References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> <64ddb72c0707080711i56b4f796sa44ad7cf243f9e41@mail.gmail.com> Message-ID: <1183904393.30496.21.camel@mindy> Am Montag, den 09.07.2007, 00:11 +1000 schrieb Ren? Dudfield: > I think the reason is that zope, and paste are not named for what they do. > > I mean, without knowing what's in them, zope and paste are kind of > abstract things for people. > > I mean if something was called zope.configurator vs configurator - > people might think the zope one is zope specific. That it's for zope, > or used with zope. > > Putting all the zope bits separately in the cheeseshop makes it more > obvious that they can be used separately. But I still keep thinking > they are zope specific things - even though I know they can be used > separately. > > Same for paste. > > That is my thinking anyway - maybe other people think that way too. That argument would make any kind of namespacing for packages futile. Would any of the gocept packages imply they are specific to gocept? Is the `sun` namespace in Java packages only for code that is used internally with sun? Why would we put it on the cheeseshop if it wasn't relevant to others as well? Maybe namespace packages did not fully arrive yet. Christian From renesd at gmail.com Sun Jul 8 16:48:45 2007 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 9 Jul 2007 00:48:45 +1000 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: <1183904393.30496.21.camel@mindy> References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> <64ddb72c0707080711i56b4f796sa44ad7cf243f9e41@mail.gmail.com> <1183904393.30496.21.camel@mindy> Message-ID: <64ddb72c0707080748j414afacfr5404c597fd1f56ba@mail.gmail.com> I guess I'm just not used to it. Adding the stuff to the cheeseshop has definitely made it more obvious that you can use the bits separately. I don't think it'll be that much longer before people realise the parts are decoupled now. Part of it could be that the names are just longer. I can easily remember things with less levels - and there's slightly less typing. There's also the history of zope stuff being for zope. I mean zope has been around for *ages* and my brain doesn't adapt as quickly as it used to. I guess the cheeseshop could be the top namespace. The zope. part isn't technically needed if the cheeseshop keeps things unique. Modules could still be under the zope umbrella without the zope. at the front. Although the zope part is in itself useful. Just to see which parts come from zope, and to organise things. If a name is already taken globally it doesn't matter because it is in the zope namespace. btw, twisted is in the same boat as paste and zope. There's lots of useful stuff in there that I overlook, possibly because in the past twisted was one big thing, and maybe because the naming isn't entirely about the functionality. On 7/9/07, Christian Theune wrote: > Am Montag, den 09.07.2007, 00:11 +1000 schrieb Ren? Dudfield: > > I think the reason is that zope, and paste are not named for what they do. > > > > I mean, without knowing what's in them, zope and paste are kind of > > abstract things for people. > > > > I mean if something was called zope.configurator vs configurator - > > people might think the zope one is zope specific. That it's for zope, > > or used with zope. > > > > Putting all the zope bits separately in the cheeseshop makes it more > > obvious that they can be used separately. But I still keep thinking > > they are zope specific things - even though I know they can be used > > separately. > > > > Same for paste. > > > > That is my thinking anyway - maybe other people think that way too. > > That argument would make any kind of namespacing for packages futile. > Would any of the gocept packages imply they are specific to gocept? > Is the `sun` namespace in Java packages only for code that is used > internally with sun? > > Why would we put it on the cheeseshop if it wasn't relevant to others as > well? > > Maybe namespace packages did not fully arrive yet. > > Christian > > From guido at python.org Sun Jul 8 16:59:08 2007 From: guido at python.org (Guido van Rossum) Date: Sun, 8 Jul 2007 16:59:08 +0200 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: On 7/8/07, Jim Fulton wrote: > Is "zc" a brand? It seems reasonable that namespace package names > should reflect organization names. If that makes them too brand- > laden, then how should people pick namespace names? Should we pick > random letters? Should I use namespaces like "python", "web", or > maybe "nice"? ;) I believe Marc-Andre *did* pick random letters (unless he has a secret nickname which I'm not aware of :-). To me, "zc" is a lot less brand-laden than "zope". I would assume "zc.frobnobulate" was simply a frobnobulation module written by someone at Zope Corp, while "zope.frobnobulate" sounds like fromnobulation support for the Zope framework. Is that not your experience? > Aside from the more general issue, in the context of web software, I > hope we can reuse each others components without having to rename > everything. What a waste of time that would be. Does this have to > be so political? I hope not. I hope the web framework developers can see beyond this. Maybe your post is helping. But I fear that the general public (or relative outsiders like myself) will have instinctive responses to these things that are hard to change. PS. Where do people meet for drinks in the Reval Hotel in Vilnius tonight? -- --Guido van Rossum (home page: http://www.python.org/~guido/) From ct at gocept.com Sun Jul 8 17:09:26 2007 From: ct at gocept.com (Christian Theune) Date: Sun, 08 Jul 2007 17:09:26 +0200 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: <64ddb72c0707080748j414afacfr5404c597fd1f56ba@mail.gmail.com> References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> <64ddb72c0707080711i56b4f796sa44ad7cf243f9e41@mail.gmail.com> <1183904393.30496.21.camel@mindy> <64ddb72c0707080748j414afacfr5404c597fd1f56ba@mail.gmail.com> Message-ID: <1183907366.18661.1.camel@mindy> Am Montag, den 09.07.2007, 00:48 +1000 schrieb Ren? Dudfield: > I guess I'm just not used to it. > > Adding the stuff to the cheeseshop has definitely made it more obvious > that you can use the bits separately. I don't think it'll be that > much longer before people realise the parts are decoupled now. > > Part of it could be that the names are just longer. I can easily > remember things with less levels - and there's slightly less typing. > > There's also the history of zope stuff being for zope. I mean zope > has been around for *ages* and my brain doesn't adapt as quickly as it > used to. zope.component and zope.interface might be of help to start adapting. ;) Overall, I think I'd give it a shot to wait for what happens after we have our first stable round of releases around. I know that there are some packages where we didn't get the dependencies right immediately, but those will be sorted out. I really hope we can solve this by having packages that are helpful and people start using it and adapting their view on what 'zope.*' means. Christian From pje at telecommunity.com Sun Jul 8 19:16:03 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun, 08 Jul 2007 13:16:03 -0400 Subject: [Web-SIG] Can't we all just get along? (was: Re: wsgiconfig design) In-Reply-To: References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: <20070708171350.B3A2C3A404D@sparrow.telecommunity.com> At 07:31 AM 7/8/2007 -0400, Jim Fulton wrote: > > I've tried to encourage people to use this, but they get stuck on the > > word "paste", so there's not many other people who consume or produce > > these entry points except for use with Paste or related packages > > (Pylons, etc). I'm not sure what to do about that, except perhaps to > > reset people's opinions with this rewrite. > >Well, this touches a nerve with me. I have a similar problem with >people rejecting out of hand anything that happens to live in the >zope or even the zc namespace. Similarly, at PyCon, I try to always >give at least talk that I think will be generally interesting to the >Python community at large, yet many people tend to assume that these >are Zope specific. I think this behavior is extremely unhealthy for >the Python community. Paste deploy is the only effort I've seen to >provided a much-needed glue layer for WSGI. It doesn't matter one >bit to me what it's called. It tries to fill a basic need. Now I'm >all for competition. If someone really wanted to come up with >something better, then I wouldn't mind seeing someone try, but >nothing else is happening AFAICT. I certainly have other things I >want to work on. Paste Deploy is a really good start and, FWIW, the >Zope community is embracing it. Just a side note, but this is one reason my CheeseShop packages are named things like "BytecodeAssembler", "DecoratorTools", "SymbolType", "ProxyTypes", etc. -- even though the actual modules contained in those packages are things like peak.util.assembler, peak.util.decorators, etc. When breaking out a formerly-monolithic package, there's usually little reason to continue the "monolithy" in package names. Understandably, Zope is different because you had an early dependency management system that *did* use the imported package names to declare dependencies. And, with the number of core Zope packages dwarfing even my array of CheeseShop packages, it's also understandable that you'd prefer not to remember two sets of names. Not that I'm all that bright here regarding names, mind you; I just went from having a package called RuleDispatch to adding a new one called PEAK-Rules... d'oh! Still, bearing this rule in mind would be good for any future monolith breakups. At least the rate of *new* monoliths seems to be decreasing, though, and the spattering of new multi-part packages on the CheeseShop seems likely to increase the public awareness that things named similarly don't necessarily require every possible piece of a brand's offerings to be installed. From ianb at colorstudy.com Sun Jul 8 22:18:04 2007 From: ianb at colorstudy.com (Ian Bicking) Date: Sun, 08 Jul 2007 15:18:04 -0500 Subject: [Web-SIG] wsgiconfig design In-Reply-To: References: <468F0B7D.9050305@colorstudy.com> <40CC5AE8-FBA1-4F10-8F45-0F00C0DFCE6D@zope.com> <468FE2EF.8080100@colorstudy.com> Message-ID: <4691467C.3050400@colorstudy.com> Jim Fulton wrote: > > On Jul 7, 2007, at 3:01 PM, Ian Bicking wrote: > >> Jim Fulton wrote: > .. >>> I do have one potential complaint about the entry-point APIs. The >>> applications my company builds have configurations that are too >>> complex to fit in a single config-parser section. To handle these >>> configurations, I'd need to be able to read multiple sections, or to >>> refer to an external configuration. I think the later is the current >>> recommended approach for Paste Deploy. If you want to keep that >>> approach, then the existing entry-point APIs are fine. (I >>> personally, want to be able to put all of my configuration in a >>> single file, but zc.buildout lets me do that, so I don't need Paste >>> Deploy to do that for me.) >> >> As I've been coding, I've actually been thinking about passing a >> complete config dictionary in instead of global_conf. So it would be >> like {section: {option: value, ...}}. > > BTW, I've become a big fan of the ConfigParser module and format, mainly > because of it's simplicity. The simplicity of a dictionary of > dictionaries is very powerful, IMO. Of course, the ConfigParser API is > pretty horrible. Fortunately, it's trivial to convert a parser object > to a mapping of mappings and that's generally one of the first things I > do after I've parsed a file. > >> This lets you look into other >> application's sections, which maybe isn't ideal. > > Why? Are you afraid that a handler will look at something it shouldn't? > Who cares? Relax. This isn't the Spanish Inquisition. :) > > Embrace the simplicity of a mapping of mappings. The problem as I see it with looking into other people's sections isn't so much that it's dangerous, as it expands the number of possible sources of a configuration bug. That is, if an application is acting in an unexpected way, you have to worry about any configuration anywhere in the file. You can't feel certain that the configuration problem is limited to some particular set of sections. >> Another option that occurs to me now might be something like >> [config:app_name section_name], and then pass in section_name={dict of >> options} as a keyword argument. I.e.: >> >> [/] >> use = egg:MyPackage >> greeting = Hello >> >> [config:/ email] >> smtp_server = localhost >> email = bob at example.com >> >> That leads to mypackage.wsgi_app(global_conf, greeting="Hello", >> email={'smtp_server': 'localhost', 'email': 'bob at example.com}) >> >> I think I prefer the latter. > > I prefer the simpler model. For one thing, it lets you share data among > multiple sections. Maybe this isn't important for Paste Deploy. Having > said that, I think your suggested is fine and is also less verbose than > the simpler approach, because, in the simpler approach, the root section > will tend to have options saying what other sections to read. > > If you are going to do something like this, then, IMO, you might also > consider: > > [/] > use = egg:MyPackage > greeting = Hello > email = > smtp_server = localhost > email = bob at example.com This will work fine already, and I use it sometimes in my applications. Of course, the application has to parse those assignments itself. But that's easy enough, and not every indented block of text is going to be a set of sub-assignments. >>>> options is a flat dictionary of options that are passed in, which the >>>> config loader can use at its discretion. A common way to use it would >>>> be for variable substitution. This allows for things like "paster >>>> serve >>>> config.ini var1=value var2=value", for ad hoc customization. It >>>> returns >>>> a single application. (This does mean that a feature from Paste Deploy >>>> is lost, where you could do "paster serve config.ini#section_name" to >>>> load a specific application from several defined in a file -- but you >>>> are less likely to get dead sections or confusing config file >>>> factorings). >>>> >>>> object_type is the kind of object we want to get out. Here I'll only >>>> specify 'wsgi.application'. 'wsgi.server' will probably also be >>>> implemented, but that's all I plan for now. 'wsgi.appserver' or >>>> something might be possible, for the process manager that runs an >>>> entire >>>> application. >>> I don't really follow this. Maybe an example would help. >> >> Well, lets say you have a configuration like: >> >> [/] >> use = egg:MyApp >> >> [middleware:/] >> use = egg:Paste#profile >> >> [server:main] # or maybe just server? >> use = egg:Paste#http >> host = 127.0.0.1:${port} >> >> Then you start it up with "serve config.ini port=8090". That's the idea >> of the options dictionary, it holds {'port': '8090'}. > > Ah, so command-line options. > > In the example, a port is something you'd want to make available in a > server section isn't it? Why do you want the loader to get command-line > options? Users have requested this. In part it's easier to ship a config file and give people instructions with some options for getting started quickly. In the implementation I just set variables in parser.defaults with these values. If you put "port = 8080" in [DEFAULT] then it'll overwrite that with your option, but work without the option too. >>>> Unlike Paste Deploy, section names will not be arbitrary. A section >>>> name has a prefix and name. The prefix, as in Paste Deploy, says what >>>> you are describing. The default prefix is "app:"; you can also give >>>> "middleware:". Prefixes not recognized will be ignored. A possible >>>> prefix might be "logging:" for logging, which if I don't implement it >>>> will be initially ignored (but someone else could handle it). >>> IMO, it would be nice *not* to reinvent yet another logging >>> configuration handler. The standard library already defines one. If >>> we don't like it, we should make it better. >> >> I don't like it, but I don't feel like improving it either ;) > > I hope you don't consider that a reason to reinvent it. I would hope > that, in the future, when someone gets that itch, they'll resist and > improve the standard one instead. > > We invented ZConfig which has it's own logging configuration "schema". > The result? It hasn't remained up to date with the logging package and > people who use it don't have access to some useful loggers without > screwing with ZConfig schemas (which isn't fun), Bad bad bad. > >> Anyway, >> this is basically just a convention to group all the sections together >> for logging based on that prefix. The logging module's configuration >> handler can handle it, > > It can? I think it looks for specific un-prefixed section names. > >> or we could wrap it slightly (if you loaded >> logging you wouldn't actually be returning anything, you'd be updating >> the global logging configuration, which may or may not be what we want). > > I'm not sure what you mean here. In theory, if you simply let people > use the sections defined by the logging module, you could point the > standard logging module at your config and be done. You could even > condition this on whether the defined sections are present. > Unfortunately, I don't speak from experience because the applications I > routinely use use ZConfig. Right now in Paste Deploy it ignores any sections that aren't specifically asked for. So you can have sections with any name, and even app: sections that just don't work as long as you don't try to use them. So having the logging module load config from it is easy, and I added that automatic parsing recently. I think you are right, it doesn't like prefixes, though I've never tried. OTOH, it must be possible to give the logging module a dict-of-dicts or some fake ConfigParser that pulls only from sections with a given prefix. This isn't reinventing the logging module's config handler, it's just giving the logging module a view onto the config file. >>>> Similarly >>>> the server as with Paste Deploy can be defined with "server:". For now >>>> all we're concerned with is applications, middleware, and composites. >>> Maybe I'm missing your point, but I thought the value of Paste Deploy >>> was to be able to have a way to define and end-to-end configuration >>> of applications, middleware and server. >> >> The server is a little bit of an outlier. The applications and >> middleware can be composed directly and fairly opaquely, but the >> server needs to be connected to the application more explicitly and >> outside of wsgiconfig. OTOH, it's real handy to be able to put the >> server section in the same config file. > > IMO, it's very important to put the server in the config. Why make the > program using the config do that? > > I really want to to be able to at least do all of the WSGI configuration > in one place. > > Note that, traditionally, Zope has allowed multiple servers to exist in > a single process. For smaller applications that can be handled by a > single process, this is a significant win. Selfishly, this isn't so > important to me as the applications ZC deals with are large scale and > have many processes so having a single server per process is the norm > for us. Others may perceive the loss though, I'm not arguing that the server shouldn't go into the config. It's just a separate part of the system, where some program gets a config file, pulls out the application and pulls out the server, and then invokes them together (what paster serve does now). It's much simpler, since a server is always defined in just a single section -- no middleware, and usually not many options. I'd like to support multiple servers too, but for now the API of the paste.server_runner entry point isn't really rich enough to do that. So I'm just going to stick with the current functionality Paste Deploy provides. People don't complain about it much, usually they are just happy enough to have easy server configuration. >>>> The applications and middleware are grouped together using the names. >>>> That is, if you have an application "/" and a middleware >>>> "middleware:/", >>>> then the middleware wraps that application. Middleware sections can >>>> have trailing numbers to indicate ordering and keep section names >>>> unique. Thus "middleware:/ 1", "middleware:/ 2", etc. Negative >>>> numbers >>>> and floats are allowed. Anything but trailing numbers is considered >>>> part of the name; thus names can have parameters or other structure. >>> Hm. Sounds a bit too magic to me. Maybe an example will make it >>> look better. :) >> >> Well, what we are trying to create is a basic >> middleware1(middleware2(app)) composition, where the app is required >> and the middleware is not. >> >> We group these together by name, with urlmap that name is a path. So >> / is the main app, /blog is the app mounted at /blog, etc. Then we >> need an ordered list of the middleware to apply. There needs to be >> some way to distinguish a middleware section from an application >> section, hence middleware:. And then a way of ordering them. We >> could use the section ordering, except duplicate section names are no >> good anyway, even if we did keep track of the order they were defined >> in. So I'm proposing a trailing number. > > Personally, I much prefer explicit composition sections, as I think you > have no. Then you simply have an option that names the nodes to be > composed in order. This is basically what Paste Deploy does now. I've found it somewhat confusing for people, in part because the section names don't really mean anything. Probably the worse problem is the middleware composition, which is solved by using shared names with the number suffixes, and that's more important to me. OTOH, I almost always use urlmap if I'm doing any kind of application composition. So I'm happy using that as a default, and just having people effectively replace "main" with "/" as the base application. I'll probably even switch the urlmap constructor to return the application itself when it gets {'/': something}, as it has no work to do. >>>> All the applications in the server are put in a single dictionary, and >>>> that is based to the composer. The composer by default is urlmap >>>> (which >>>> also includes optional host-based dispatch). You can specify another >>>> composer with a global option "composer = (specifier)" >>> I'm not sure how I feel about that. >> >> What would be the problem? > > I'd prefer the composers be more explicitly part of the configuration. > That is, a composer is defined with a section, like everything else. Yeah, that would be fine, i.e., "[composer] use = foo" instead of "composer = foo". >> That is, you have to be able to say, "for this application, get the >> application from this other file". That could simply be: >> >> [/blog] >> use = egg:WSGIConfig#load_config >> config_file = blog.ini >> >> But that's kind of awkward, so I think it would be better if there was >> a clearer construct. blog.ini might itself have internal structure >> and multiple applications, so we can't just use config file inlining >> to accomplish this. > > I mainly think this is a different concept and should have a separate > option name, whatever syntax is used. Yeah, maybe "from_file = filename". Probably the [DEFAULT] from the first file would be passed in as options to the second file...? This might be confusing, I'm not sure. An explain mode might make it more obvious. >> If you are restrictive in your entry point and don't include **kw, >> then you can raise errors about misspelled configuration. > > Sure, but don't options put in DEFAULT appear everywhere? Won't that > make it impossible to avoid **kw and to complain about unrecognized > options? global_conf currently contains stuff from [DEFAULT], I don't pass it in as **kw. I basically filter out all options where parser.defaults contains the same value. Using INITools it actually keeps them fully separate, so that's not a problem. The point of global_conf is specifically to give a place for unconstrained settings that aren't necessarily intended for every application. One issue, though, is that frameworks like Pylons set up their handlers with **kw, because it's a lot easier to tell your users that they simply have to add a setting in their config file and it'll be available. You can't do access tracking either, because that setting might only be used in one controller in the application. So they lose option checking. OTOH, if someone wants to add polish to their application, it's easy enough to do a grep for settings and edit your wsgiapp.py file to have a specific signature. -- Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers From nslater at gmail.com Tue Jul 10 01:53:20 2007 From: nslater at gmail.com (Noah Slater) Date: Tue, 10 Jul 2007 00:53:20 +0100 Subject: [Web-SIG] Fwd: Packaging wsgiref for Debian In-Reply-To: <9ea1c1180707091651k44a86fabof7e2392cca26aa48@mail.gmail.com> References: <9ea1c1180707091651k44a86fabof7e2392cca26aa48@mail.gmail.com> Message-ID: <9ea1c1180707091653p7b614c61oe16265df5b1d4987@mail.gmail.com> Hello, I want to package the wsgiref package for Debian but am unsure what text to use for the licence section of the package. The PSF recommends the following text: Python 1.6, beta 1, is made available subject to the terms and conditions in CNRIs License Agreement. This Agreement may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1011. This Agreement may also be obtained from a proxy server on the Internet using the URL: http://hdl.handle.net/1895.22/1011 Clearly this is inaccurate as I am packaging wsgiref and not Python 1.6, beta 1 - should I change this paragraph to read: The software is made available subject to the terms and conditions in CNRIs License Agreement. This Agreement may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1011. This Agreement may also be obtained from a proxy server on the Internet using the URL: http://hdl.handle.net/1895.22/1011 I don't know if this invalidates the licence however. Thanks for you help, Noah -- "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman From pje at telecommunity.com Tue Jul 10 03:58:29 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 09 Jul 2007 21:58:29 -0400 Subject: [Web-SIG] Fwd: Packaging wsgiref for Debian In-Reply-To: <9ea1c1180707091653p7b614c61oe16265df5b1d4987@mail.gmail.co m> References: <9ea1c1180707091651k44a86fabof7e2392cca26aa48@mail.gmail.com> <9ea1c1180707091653p7b614c61oe16265df5b1d4987@mail.gmail.com> Message-ID: <20070710015616.5ED773A404D@sparrow.telecommunity.com> At 12:53 AM 7/10/2007 +0100, Noah Slater wrote: >Hello, > >I want to package the wsgiref package for Debian but am unsure what >text to use for the licence section of the package. The PSF recommends >the following text: Not since Python 2.0, it hasn't. :) The source you got this from should be corrected. >Clearly this is inaccurate as I am packaging wsgiref and not Python >1.6, beta 1 - should I change this paragraph to read: wsgiref is available for use under several licenses, including the Python 2.0 license, which you can find here: http://www.python.org/download/releases/2.5/license/ From pje at telecommunity.com Tue Jul 10 04:10:44 2007 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 09 Jul 2007 22:10:44 -0400 Subject: [Web-SIG] Fwd: Packaging wsgiref for Debian In-Reply-To: <9ea1c1180707091900t47e7c864lfca70053978e272e@mail.gmail.co m> References: <9ea1c1180707091651k44a86fabof7e2392cca26aa48@mail.gmail.com> <9ea1c1180707091653p7b614c61oe16265df5b1d4987@mail.gmail.com> <20070710015616.5ED773A404D@sparrow.telecommunity.com> <9ea1c1180707091900t47e7c864lfca70053978e272e@mail.gmail.com> Message-ID: <20070710020830.2DABA3A404D@sparrow.telecommunity.com> At 03:00 AM 7/10/2007 +0100, Noah Slater wrote: >>http://www.python.org/download/releases/2.5/license/ > >This recommends the use of: > >"Python 1.6.1 is made available subject to the terms and >conditions in CNRI's License Agreement. This Agreement together with >Python 1.6.1 may be located on the Internet using the following >unique, persistent identifier (known as a handle): 1895.22/1013. This >Agreement may also be obtained from a proxy server on the Internet >using the following URL: http://hdl.handle.net/1895.22/1013" > >Should I replace "Python 1.6.1" with something else or just leave it? That's part of the license for 1.6. You want this part: PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2 -------------------------------------------- 1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using this software ("Python") in source or binary form and its associated documentation. 2. Subject to the terms and conditions of this License Agreement, PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version, provided, however, that PSF's License Agreement and PSF's notice of copyright, i.e., "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006 Python Software Foundation; All Rights Reserved" are retained in Python alone or in any derivative version prepared by Licensee. 3. In the event Licensee prepares a derivative work that is based on or incorporates Python or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python. 4. PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between PSF and Licensee. This License Agreement does not grant permission to use PSF trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By copying, installing or otherwise using Python, Licensee agrees to be bound by the terms and conditions of this License Agreement. From nslater at gmail.com Tue Jul 10 15:06:18 2007 From: nslater at gmail.com (Noah Slater) Date: Tue, 10 Jul 2007 14:06:18 +0100 Subject: [Web-SIG] Fwd: Packaging wsgiref for Debian In-Reply-To: <20070710020830.2DABA3A404D@sparrow.telecommunity.com> References: <9ea1c1180707091651k44a86fabof7e2392cca26aa48@mail.gmail.com> <9ea1c1180707091653p7b614c61oe16265df5b1d4987@mail.gmail.com> <20070710015616.5ED773A404D@sparrow.telecommunity.com> <9ea1c1180707091900t47e7c864lfca70053978e272e@mail.gmail.com> <20070710020830.2DABA3A404D@sparrow.telecommunity.com> Message-ID: <9ea1c1180707100606nbccdb28tcd77613cc540bcb1@mail.gmail.com> Thank you. From arnarbi at gmail.com Wed Jul 11 05:18:43 2007 From: arnarbi at gmail.com (Arnar Birgisson) Date: Wed, 11 Jul 2007 03:18:43 +0000 Subject: [Web-SIG] Stackless WSGI server Message-ID: <28012bc60707102018u35095a00j1ab9933bb573c461@mail.gmail.com> Hi all, I'm sorry if this is an inappropriate place to post this, but for anyone interested - I've posted a port of CherryPy's WSGI server to use Stackless tasklets instead of threads up on http://code.google.com/p/stacklessexamples/wiki/StacklessWSGI. There are also two example WSGI apps - one that allows one invocation of a controller to span several requests, rendering "sessions" useless :) cheers, Arnar