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@colorstudy.com : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers