[Distutils] [Web-SIG] entry points, etc
Ian Bicking
ianb at colorstudy.com
Sat Jul 7 21:12:11 CEST 2007
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
More information about the Distutils-SIG
mailing list