On 14 April 2015 at 17:10, Chris Barker <chris.bar...@noaa.gov> wrote: >> If there’s a plugin that understands this extension >> > installed, let it do something before you actually move the files into >> > place”. This let’s Wheels themselves still be declarative and moves the >> > responsibility of implementing these bits into their own PyPI projects >> > that can be versioned and independently upgraded and such. We’d probably >> > need some method of marking an extension as “critical” (e.g. bail out >> > and >> > don’t install this Wheel if you don’t have something that knows how to >> > handle >> > it) and then non critical extensions just get ignored if we don’t know >> > how to handle it. > > Could an "extension" be -- "run this arbitrary Python script" ?
The main point (as I see it) of an "extension" is that it's distributed independently of the packages that use it. So you get to decide to use an extension (and by inference audit it if you want) *before* it gets run as part of an installation. Extensions get peer review by the community, and bad ones get weeded out, in a way that just having a chunk of code in your setup.py or the postinstall section of your wheel doesn't. > We've got a full featured scripting language (with batteries included!) -- > isn't that all the extension you need? Up to a point yes. It's the independent review and quality control aspects that matter to me. > Or is this about security? We don't want to let a package do virtually > anything on install? Security is one aspect, and one that a lot of people will pick up on immediately. But there's also portability. And code quality. And consistency. I'd be much happier installing a project that used a well-known "start menu manager extension" than one that just used custom code. I'd be willing to assume that the author of the extension had thought about Unix/Windows compatibility, how to handle use in a virtualenv, handling user preferences (such as the end user *not wanting* shortcuts), etc etc. And I could look at the extension project's issue tracker to see how happy I was with the state of the project. Of course, if the project I want to install makes using the extension mandatory for the install to work, I still don't have a real choice - I accept the extension or I can't use the code I want - but there's an extra level of transparency involved. And hopefully most extensions will be optional, in practice. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
