[Web-SIG] entry points, etc

[Ian Bicking]

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