On 18 April 2015 at 13:36, Paul Moore <[email protected]> wrote: > On 18 April 2015 at 18:19, Chris Barker - NOAA Federal > <[email protected]> wrote: > > (your quote trimming's a bit over-enthusiastic, you lost the attribution here) > >>> "python -m something" rather than just "something" isn't broken, it's >>> just an inconvenience. >> >> Tell that to a newbie. This is EXACTLY the kind of thing that should >> "just work". > > It's a huge "quality of implementation" issue, certainly - any > installer that doesn't include script generation built in is going to > be as annoying as hell to a user. But they do exist (wheel install, > for instance) and the resulting installation "works", even if a > newcomer would hate it. So it's not "mandatory" in the sense that no > functionality is lost. But this is a moot point, as PEP 459 says the > python.commands extension SHOULD be marked as required. And wheel > install would technically be in violation of PEP 426, as it doesn't > handle script wrappers and it doesn't fail when a package needs them > (only "technically", because PEP 426 isn't finalised yet, and "wheel > install" could be updated to support it).
It's not in violation, that's the whole point of saying SHOULD, rather than MUST. Please don't lose that distinction - if users start demanding that developers always implement SHOULDs, they're misreading the spec, and are going to make life miserable for a lot of people by making unreasonable demands on their time. As a specification author, "SHOULD" is a way for us to say "most users are likely to want this, so you should probably do it if you don't have a strong preference, but not all users will want it, so certain tools may choose not to do it for reasons that are too context specific for us to go into in a general purpose specification". The MUSTs are the "things you may not personally care about, but other people do care about, will break if you get this wrong" part of the specs, the SHOULDs are "this is probably a good thing to do, but you may disagree" :) Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
