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 : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
