Re: [Distutils] Major update to the metadata 2.0 draft PEPs
On 2 Jan 2014 03:59, "PJ Eby" wrote: > > On Wed, Jan 1, 2014 at 9:39 AM, Nick Coghlan wrote: > > On 1 Jan 2014 10:33, "PJ Eby" wrote: > >> I have only been skimming these so far, will comment more later, but I > >> just want to mention that for standard extensions, what is the > >> rationale for not defining e.g. commands as exports? Or for that > >> matter, defining hooks as exports? Both commands and hooks have a > >> payload that's the same as an export payload, i.e., a reference to an > >> importable object. I think it'd be good for them to be defined in > >> terms of exports in order to reduce duplication of concepts and > >> implementations, as well as providing a PEP-defined example of how to > >> use export groups and export names effectively. > > > > I believe it was due to the extra layer of nesting they needed - using > > multiple parallel export groups with different final elements in their > > dotted names didn't feel right. > > > > I guess that indicates a flaw in my initial design for the export > > definitions though - I agree it would be better if commands and hooks could > > be cleanly defined within the exports mechanism, rather than needing > > separate custom metadata extensions. > > If it's a flaw, I'd say it's in my original design of entry points. > ;-) Basically, I wanted a way to do -- without XML -- what Eclipse > does with its "extensions" and "extension points" machinery. I went > with a "flat (with dots) is better than nested" concept. > > To me, though, this doesn't look terribly complicated (using entry > points syntax): > > [python.exports.after_install] > ComfyChair.plugins = ComfyChair.plugins:install_hook > > [python.exports.after_uninstall] > ComfyChair.plugins = ComfyChair.plugins:install_hook > > Nor this: > > [python.extensions.after_install] > python.exports = pip.export_group_hooks:run_install_hooks > python.commands = pip.command_hook:install_wrapper_scripts > > [python.extensions.after_uninstall] > python.exports = pip.export_group_hooks:run_uninstall_hooks > > (Also, adding hooks to *validate* extensions and exports at build > and/or install time might be handy.) > > Finally, note that if the typical usecase is to define *both* an > install and uninstall hook, then it might be simpler to just define > the hook once, as an object with 'after_install' and 'after_uninstall' > methods. This avoids the need to register a hook in two groups, and > in the simplest case people can just make them both module-level > functions and list the module as the export. Ah, true - people could provide them as either functions or class methods, and if we add a new one, only the list of permitted names (and their signatures) needs to change. And splitting commands into python.commands and python.commands.gui export groups would cover the export compatible cases. Since identifying "prebuilt commands" in the metadata is a new feature without any particularly compelling justification at this point, I'll likely just leave it out for 2.0. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Major update to the metadata 2.0 draft PEPs
On Wed, Jan 1, 2014 at 9:39 AM, Nick Coghlan wrote: > On 1 Jan 2014 10:33, "PJ Eby" wrote: >> I have only been skimming these so far, will comment more later, but I >> just want to mention that for standard extensions, what is the >> rationale for not defining e.g. commands as exports? Or for that >> matter, defining hooks as exports? Both commands and hooks have a >> payload that's the same as an export payload, i.e., a reference to an >> importable object. I think it'd be good for them to be defined in >> terms of exports in order to reduce duplication of concepts and >> implementations, as well as providing a PEP-defined example of how to >> use export groups and export names effectively. > > I believe it was due to the extra layer of nesting they needed - using > multiple parallel export groups with different final elements in their > dotted names didn't feel right. > > I guess that indicates a flaw in my initial design for the export > definitions though - I agree it would be better if commands and hooks could > be cleanly defined within the exports mechanism, rather than needing > separate custom metadata extensions. If it's a flaw, I'd say it's in my original design of entry points. ;-) Basically, I wanted a way to do -- without XML -- what Eclipse does with its "extensions" and "extension points" machinery. I went with a "flat (with dots) is better than nested" concept. To me, though, this doesn't look terribly complicated (using entry points syntax): [python.exports.after_install] ComfyChair.plugins = ComfyChair.plugins:install_hook [python.exports.after_uninstall] ComfyChair.plugins = ComfyChair.plugins:install_hook Nor this: [python.extensions.after_install] python.exports = pip.export_group_hooks:run_install_hooks python.commands = pip.command_hook:install_wrapper_scripts [python.extensions.after_uninstall] python.exports = pip.export_group_hooks:run_uninstall_hooks (Also, adding hooks to *validate* extensions and exports at build and/or install time might be handy.) Finally, note that if the typical usecase is to define *both* an install and uninstall hook, then it might be simpler to just define the hook once, as an object with 'after_install' and 'after_uninstall' methods. This avoids the need to register a hook in two groups, and in the simplest case people can just make them both module-level functions and list the module as the export. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Major update to the metadata 2.0 draft PEPs
On Wed, 1/1/14, Nick Coghlan wrote: > I guess that indicates a flaw in my initial design for the export definitions > though - I agree it would > be better if commands and hooks could be cleanly defined within the exports > mechanism, rather > than needing separate custom metadata extensions. +1. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Major update to the metadata 2.0 draft PEPs
On 1 Jan 2014 10:33, "PJ Eby" wrote: > > On Sat, Dec 21, 2013 at 9:46 AM, Nick Coghlan wrote: > > I've just published the first draft of the metadata 2.0 spec that > > moves all of the fields that aren't part of the core metadata or > > potentially needed for dependency resolution out to a separate > > "standard metadata extensions" PEP. > > Yay! > > > > I think this makes PEP 426 itself substantially less overwhelming, and > > also provides convenient names to refer to the various other subsets > > of the metadata. > > Indeed! > > > > Metadata 2.0: http://www.python.org/dev/peps/pep-0426/ > > Versioning: http://www.python.org/dev/peps/pep-0440/ > > Standard Extensions: http://www.python.org/dev/peps/pep-0459/ > > I have only been skimming these so far, will comment more later, but I > just want to mention that for standard extensions, what is the > rationale for not defining e.g. commands as exports? Or for that > matter, defining hooks as exports? Both commands and hooks have a > payload that's the same as an export payload, i.e., a reference to an > importable object. I think it'd be good for them to be defined in > terms of exports in order to reduce duplication of concepts and > implementations, as well as providing a PEP-defined example of how to > use export groups and export names effectively. I believe it was due to the extra layer of nesting they needed - using multiple parallel export groups with different final elements in their dotted names didn't feel right. I guess that indicates a flaw in my initial design for the export definitions though - I agree it would be better if commands and hooks could be cleanly defined within the exports mechanism, rather than needing separate custom metadata extensions. I'll take another look at using either parallel export groups, or else allowing subdivision of export groups as a general feature. > (Also, noting the > mapping of current script export namespaces to the new metadata would > be helpful for people implementing translation tools from setuptools > metadata.) > > Last but not least, some of the export examples should use dotted > post-module names (e.g. "some.module:RandomClass.a_class_method") to > highlight that qualified names can be used there. (Yes, the spec > *says* qualified names, but it's the sort of thing that people > overlook when the examples are all of unqualified simple names.) Yeah, those are both good ideas. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] migration path for entry_points?
On 1 Jan 2014 20:58, "Paul Moore" wrote: > > On 31 December 2013 22:53, Marcus Smith wrote: > > for #1, during installation, I imagine the new setuptools would build the > > sdist (and any entry_point declarations) using 2.0 metadata. > > So assuming the package consuming the entry point converts to using > metadata 2.0 APIs (and does *not* try to have a compatibility mode > that falls back to the old setuptools format) users would be required > to use an up to date setuptools (installation with older setuptools > would be unsupported). Also they would need to reinstall SomeExtension > for it to be recognised by the new consumer. > > > for #2, the pip installer would be responsible for converting > > "entry_points.txt" during the install (or maybe just forcing a "bdist_wheel" > > rebuild when it detects metadata < 2.0) > > Again requiring users to be running a suitably recent pip and/or > setuptools and reinstall SomeExtension. > > Presumably the new setuptools and pip would have to maintain both the > Metadata 2.0 format data and the old-style entry_points.txt format for > a period of compatibility. We should probably define the length of > that transition period as part of the plan for Metadata 2.0 going > live. > > So there is some user impact, but it sounds like it's manageable. Cool. Yeah, one of the big benefits of switching to the JSON format with a different filename was letting us distribute both the old and new metadata formats in parallel. The aim is to allow newer versions of pip and setuptools to be faster and more reliable, without breaking older versions. Cheers, Nick. > > Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] migration path for entry_points?
On 31 December 2013 22:53, Marcus Smith wrote: > for #1, during installation, I imagine the new setuptools would build the > sdist (and any entry_point declarations) using 2.0 metadata. So assuming the package consuming the entry point converts to using metadata 2.0 APIs (and does *not* try to have a compatibility mode that falls back to the old setuptools format) users would be required to use an up to date setuptools (installation with older setuptools would be unsupported). Also they would need to reinstall SomeExtension for it to be recognised by the new consumer. > for #2, the pip installer would be responsible for converting > "entry_points.txt" during the install (or maybe just forcing a "bdist_wheel" > rebuild when it detects metadata < 2.0) Again requiring users to be running a suitably recent pip and/or setuptools and reinstall SomeExtension. Presumably the new setuptools and pip would have to maintain both the Metadata 2.0 format data and the old-style entry_points.txt format for a period of compatibility. We should probably define the length of that transition period as part of the plan for Metadata 2.0 going live. So there is some user impact, but it sounds like it's manageable. Cool. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
