Re: [Distutils] PEP 426: proposed change to extension fields + entry points
Nick Coghlan
The other area where I think such an "embedded JSON" approach could work is coming up with a clean format for an Entry-Points field. Specifically, I am thinking of proposing the setuptools.setup inspired:
Entry-Points: { "console_scripts": { "foo": "my_package.some_module:main_func", "bar": "other_module:some_func" }, "gui_scripts": { "baz": "my_package_gui.start_func" } }
What is the reason for this half-way-house, rather than going straight to JSON? I suppose one could argue backward compatibility, but since we are moving quite a distance from a plain old key-value here, we may as well embrace JSON properly. Perhaps we should embrace the dict rather than any specific file format, as I did with dictConfig in logging. Note that distlib already supports entry points, though these are called "exports" because they may or may not be callable code. (The name "exports" was suggested by PJE and, IMO, is better/more general than "entry points"). For example, for Babel-0.9.6: "exports": { "babel.extractors": [ "ignore = babel.messages.extract:extract_nothing", "python = babel.messages.extract:extract_python", "javascript = babel.messages.extract:extract_javascript" ], "distutils.commands": [ "compile_catalog = babel.messages.frontend:compile_catalog", "extract_messages = babel.messages.frontend:extract_messages", "init_catalog = babel.messages.frontend:init_catalog", "update_catalog = babel.messages.frontend:update_catalog" ], "babel.checkers": [ "num_plurals = babel.messages.checkers:num_plurals", "python_format = babel.messages.checkers:python_format" ], "distutils.setup_keywords": [ "message_extractors = babel.messages.frontend:check_message_extractors" ], "scripts": { "console": [ "pybabel = babel.messages.frontend:main" ] } } This is currently used, for example, in distlib's script generation logic (for example, to generate the pybabel script for Babel). Regards, Vinay Sajip
I can accept a rename but there is no way to avoid having 2 names not 1 new
name for the feature.
We go halfway now. The next version can go any other way.
On Feb 25, 2013 12:23 PM, "Vinay Sajip"
Nick Coghlan
writes: The other area where I think such an "embedded JSON" approach could work is coming up with a clean format for an Entry-Points field. Specifically, I am thinking of proposing the setuptools.setup inspired:
Entry-Points: { "console_scripts": { "foo": "my_package.some_module:main_func", "bar": "other_module:some_func" }, "gui_scripts": { "baz": "my_package_gui.start_func" } }
What is the reason for this half-way-house, rather than going straight to JSON? I suppose one could argue backward compatibility, but since we are moving quite a distance from a plain old key-value here, we may as well embrace JSON properly. Perhaps we should embrace the dict rather than any specific file format, as I did with dictConfig in logging.
Note that distlib already supports entry points, though these are called "exports" because they may or may not be callable code. (The name "exports" was suggested by PJE and, IMO, is better/more general than "entry points").
For example, for Babel-0.9.6:
"exports": { "babel.extractors": [ "ignore = babel.messages.extract:extract_nothing", "python = babel.messages.extract:extract_python", "javascript = babel.messages.extract:extract_javascript" ], "distutils.commands": [ "compile_catalog = babel.messages.frontend:compile_catalog", "extract_messages = babel.messages.frontend:extract_messages", "init_catalog = babel.messages.frontend:init_catalog", "update_catalog = babel.messages.frontend:update_catalog" ], "babel.checkers": [ "num_plurals = babel.messages.checkers:num_plurals", "python_format = babel.messages.checkers:python_format" ], "distutils.setup_keywords": [ "message_extractors = babel.messages.frontend:check_message_extractors" ], "scripts": { "console": [ "pybabel = babel.messages.frontend:main" ] } }
This is currently used, for example, in distlib's script generation logic (for example, to generate the pybabel script for Babel).
Regards,
Vinay Sajip
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Daniel Holth
I can accept a rename but there is no way to avoid having 2 names not 1 new name for the feature. We go halfway now. The next version can go any other way.
Just to be clear, the naming of "exports" vs. "entry points" was not the main thrust of my point - I mentioned it purely by way of explaining that part of the JSON snippet I posted. What I meant to say is that that parsing or writing a JSON file called entry_points.txt (or whatever) is just as easy as parsing or writing an ini-format file. However, the benefit of JSON is clear when composing a larger set of data from separate files (see the separate thread about metadata caching). One can more easily compose the data in entry_points.txt, METADATA, requires-dist.txt and anything else if they are just JSON files. That is what I do in my JSON metadata format - the dependency information is extracted from the metadata for a release into an aggregated form which is easier to use when doing dependency resolution. Regards, Vinay Sajip
On Mon, Feb 25, 2013 at 12:37 PM, Vinay Sajip
Daniel Holth
writes: I can accept a rename but there is no way to avoid having 2 names not 1 new name for the feature. We go halfway now. The next version can go any other way.
Just to be clear, the naming of "exports" vs. "entry points" was not the main thrust of my point - I mentioned it purely by way of explaining that part of the JSON snippet I posted.
What I meant to say is that that parsing or writing a JSON file called entry_points.txt (or whatever) is just as easy as parsing or writing an ini-format file. However, the benefit of JSON is clear when composing a larger set of data from separate files (see the separate thread about metadata caching).
One can more easily compose the data in entry_points.txt, METADATA, requires-dist.txt and anything else if they are just JSON files. That is what I do in my JSON metadata format - the dependency information is extracted from the metadata for a release into an aggregated form which is easier to use when doing dependency resolution.
We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious way to make a Python package this decade based on the idea that something better might be just around the corner or that the current way will be deprecated. The goal of this version of the PEP is to better represent important setuptools metadata statically while imposing as near to zero cost as possible on the actual setuptools users. They will not welcome an unproven alternative that requires work on their part. Instead, we change things a little bit, support setuptools / distribute OR "something else" for 5 years, until "something else" is obviously, compellingly better.
We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious way to make a Python package this decade
Daniel Holth
The goal of this version of the PEP is to better represent important
setuptools metadata statically while imposing as near to zero cost as possible on the actual setuptools users. They will not welcome an unproven alternative that requires work on their part. Instead, we change things a little bit, support setuptools / distribute OR "something else" for 5 years, until "something else" is obviously, compellingly better. I'm not sure what work we're asking setuptools *users* to do: IIUC, the setuptools files in .egg-info and the corresponding ones in .dist-info are not edited by hand by users. As far as I can see, having JSON-format files will not adversely impact the workload for anyone, compared with the suggestion that Nick made (embedding JSON in specific parts of a key-value format) and which I was responding to. Regards, Vinay Sajip
We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious way to make a Python package this decade
All I'm trying to say is do not add anything else to pep 426. There will be
other versions. This version can be consumed by distutils as of last July.
Daniel Holth
The goal of this version of the PEP is to better represent important
setuptools metadata statically while imposing as near to zero cost as possible on the actual setuptools users. They will not welcome an unproven alternative that requires work on their part. Instead, we change things a little bit, support setuptools / distribute OR "something else" for 5 years, until "something else" is obviously, compellingly better. I'm not sure what work we're asking setuptools *users* to do: IIUC, the setuptools files in .egg-info and the corresponding ones in .dist-info are not edited by hand by users. As far as I can see, having JSON-format files will not adversely impact the workload for anyone, compared with the suggestion that Nick made (embedding JSON in specific parts of a key-value format) and which I was responding to. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
by which I mean distribute
On Feb 25, 2013 5:55 PM, "Daniel Holth"
All I'm trying to say is do not add anything else to pep 426. There will be other versions. This version can be consumed by distutils as of last July. Daniel Holth
writes: We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious way to make a Python package this decade based on the idea that something better might be just around the corner or that the current way will be deprecated.
The goal of this version of the PEP is to better represent important setuptools metadata statically while imposing as near to zero cost as possible on the actual setuptools users. They will not welcome an unproven alternative that requires work on their part. Instead, we change things a little bit, support setuptools / distribute OR "something else" for 5 years, until "something else" is obviously, compellingly better.
I'm not sure what work we're asking setuptools *users* to do: IIUC, the setuptools files in .egg-info and the corresponding ones in .dist-info are not edited by hand by users.
As far as I can see, having JSON-format files will not adversely impact the workload for anyone, compared with the suggestion that Nick made (embedding JSON in specific parts of a key-value format) and which I was responding to.
Regards,
Vinay Sajip
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
participants (2)
-
Daniel Holth -
Vinay Sajip