
I propose mapping a typical entry_points.txt to Metadata 1.3 like so:
[pyramid.scaffold] starter=pyramid.scaffolds:StarterProjectTemplate zodb=pyramid.scaffolds:ZODBProjectTemplate alchemy=pyramid.scaffolds:AlchemyProjectTemplate [console_scripts] bfg2pyramid = pyramid.fixers.fix_bfg_imports:main pcreate = pyramid.scripts.pcreate:main pserve = pyramid.scripts.pserve:main pshell = pyramid.scripts.pshell:main proutes = pyramid.scripts.proutes:main pviews = pyramid.scripts.pviews:main ptweens = pyramid.scripts.ptweens:main prequest = pyramid.scripts.prequest:main [paste.server_runner] wsgiref = pyramid.scripts.pserve:wsgiref_server_runner cherrypy = pyramid.scripts.pserve:cherrypy_server_runner
Extension: Entry-Point Entry-Point/pyramid.scaffold: starter=pyramid.scaffolds:StarterProjectTemplate Entry-Point/paste.server_runner: wsgiref = pyramid.scripts.pserve:wsgiref_server_runner

On Thu, 2012-09-13 at 01:50 -0400, Daniel Holth wrote:
I propose mapping a typical entry_points.txt to Metadata 1.3 like so:
[pyramid.scaffold] starter=pyramid.scaffolds:StarterProjectTemplate zodb=pyramid.scaffolds:ZODBProjectTemplate alchemy=pyramid.scaffolds:AlchemyProjectTemplate [console_scripts] bfg2pyramid = pyramid.fixers.fix_bfg_imports:main pcreate = pyramid.scripts.pcreate:main pserve = pyramid.scripts.pserve:main pshell = pyramid.scripts.pshell:main proutes = pyramid.scripts.proutes:main pviews = pyramid.scripts.pviews:main ptweens = pyramid.scripts.ptweens:main prequest = pyramid.scripts.prequest:main [paste.server_runner] wsgiref = pyramid.scripts.pserve:wsgiref_server_runner cherrypy = pyramid.scripts.pserve:cherrypy_server_runner
Extension: Entry-Point Entry-Point/pyramid.scaffold: starter=pyramid.scaffolds:StarterProjectTemplate Entry-Point/paste.server_runner: wsgiref = pyramid.scripts.pserve:wsgiref_server_runner
I see nothing wrong with this as long as it's understood that individual "Entry-Point/foo" lines can be multiple use. The spec only indicates that the "Entry-Point" moniker itself is multiple use.
- C

On Thu, Sep 13, 2012 at 4:04 AM, Chris McDonough chrism@plope.com wrote:
On Thu, 2012-09-13 at 01:50 -0400, Daniel Holth wrote:
I propose mapping a typical entry_points.txt to Metadata 1.3 like so:
[pyramid.scaffold] starter=pyramid.scaffolds:StarterProjectTemplate zodb=pyramid.scaffolds:ZODBProjectTemplate alchemy=pyramid.scaffolds:AlchemyProjectTemplate [console_scripts] bfg2pyramid = pyramid.fixers.fix_bfg_imports:main pcreate = pyramid.scripts.pcreate:main pserve = pyramid.scripts.pserve:main pshell = pyramid.scripts.pshell:main proutes = pyramid.scripts.proutes:main pviews = pyramid.scripts.pviews:main ptweens = pyramid.scripts.ptweens:main prequest = pyramid.scripts.prequest:main [paste.server_runner] wsgiref = pyramid.scripts.pserve:wsgiref_server_runner cherrypy = pyramid.scripts.pserve:cherrypy_server_runner
Extension: Entry-Point Entry-Point/pyramid.scaffold: starter=pyramid.scaffolds:StarterProjectTemplate Entry-Point/paste.server_runner: wsgiref = pyramid.scripts.pserve:wsgiref_server_runner
I see nothing wrong with this as long as it's understood that individual "Entry-Point/foo" lines can be multiple use. The spec only indicates that the "Entry-Point" moniker itself is multiple use.
Of course. It would be a dumb translation of the old file, with the same semantics.
Alternatively it could just mention the [sections] and keep entry-points.txt
I don't suppose there is any meaningful performance difference either way. I think we will have to parse every METADATA most of the time any packaging queries are made with this system.

On Thu, Sep 13, 2012 at 8:23 AM, Daniel Holth dholth@gmail.com wrote:
On Thu, Sep 13, 2012 at 4:04 AM, Chris McDonough chrism@plope.com wrote:
On Thu, 2012-09-13 at 01:50 -0400, Daniel Holth wrote:
I propose mapping a typical entry_points.txt to Metadata 1.3 like so:
[pyramid.scaffold] starter=pyramid.scaffolds:StarterProjectTemplate zodb=pyramid.scaffolds:ZODBProjectTemplate alchemy=pyramid.scaffolds:AlchemyProjectTemplate [console_scripts] bfg2pyramid = pyramid.fixers.fix_bfg_imports:main pcreate = pyramid.scripts.pcreate:main pserve = pyramid.scripts.pserve:main pshell = pyramid.scripts.pshell:main proutes = pyramid.scripts.proutes:main pviews = pyramid.scripts.pviews:main ptweens = pyramid.scripts.ptweens:main prequest = pyramid.scripts.prequest:main [paste.server_runner] wsgiref = pyramid.scripts.pserve:wsgiref_server_runner cherrypy = pyramid.scripts.pserve:cherrypy_server_runner
Extension: Entry-Point Entry-Point/pyramid.scaffold: starter=pyramid.scaffolds:StarterProjectTemplate Entry-Point/paste.server_runner: wsgiref = pyramid.scripts.pserve:wsgiref_server_runner
I see nothing wrong with this as long as it's understood that individual "Entry-Point/foo" lines can be multiple use. The spec only indicates that the "Entry-Point" moniker itself is multiple use.
Of course. It would be a dumb translation of the old file, with the same semantics.
Alternatively it could just mention the [sections] and keep entry-points.txt
I don't suppose there is any meaningful performance difference either way. I think we will have to parse every METADATA most of the time any packaging queries are made with this system. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
I don't see the point of jamming all metadata into a single file. Well, I mean, I do see it if you want to pull a single file off of PyPI and know everything about a distribution.
But for runtime performance, separate files are better because then you don't have to actually read them for a bunch of projects with no entry points. Putting the entry points in a file that *every* installed distribution has is going to positively murder the performance.

I don't see the point of jamming all metadata into a single file. Well, I mean, I do see it if you want to pull a single file off of PyPI and know everything about a distribution.
But for runtime performance, separate files are better because then you don't have to actually read them for a bunch of projects with no entry points. Putting the entry points in a file that *every* installed distribution has is going to positively murder the performance.
Agreed. I will let entry_points.txt stay as is.
participants (3)
-
Chris McDonough
-
Daniel Holth
-
PJ Eby