[Distutils] How to handle launcher script importability?

[Donald Stufft]

On Aug 21, 2013, at 6:56 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> Paul Moore <p.f.moore <at> gmail.com> writes:
> 
>> My problem is that as someone who wants to implement code that uses the
>> new features like wheels, I want a usable reference implementation that
>> covers the (agreed) standards. I don't particularly want my application
>> to incorporate support for extensions to the standard, nor do I want to
>> have to implement my own support all the time.
> 
> The wheel implementation in distlib conforms to the existing PEPs, as far as
> I know. It covers the agreed standards and, as far as I know, in a
> reasonable way. Why should you care if there are additional methods in a
> Wheel class, if you never call on them? It seems a step too far for a spec
> of this type to dictate precisely what specific methods should or should not
> be present in a class. If you find that distlib's behaviour somehow violates
> the agreed standards, please tell me how and I'll fix it. I think I've been
> pretty responsive on issues raised, but please don't raise vague fears if
> they have no basis in fact.

The spec does not and will not dictate what particular feature any one
implementation has or does not have other than the base set outlined
in the spec.

> 
>> In particular, at the present time there are two tools that can generate
>> wheels (bdist_wheel and distlib) and 3 that can install them (wheel,
>> distlib and pip). They have subtly different behaviours outside of the
>> standard definitions, which means that they are not completely
>> interoperable. I am not happy at all about that - and if that counts as
>> "being against innovation", then I'm afraid that yes, I am... (I don't
>> think it does, by the way, but you may differ).
> 
> As I understand it, any interoperability issues are an effect of everything
> being a work in progress and some implementations lagging behind others in
> terms of PEP compliance. I can't speak for Daniel, but I've certainly made
> efforts to ensure that distlib can work with wheel-produced wheels, even
> where it means using old METADATA and entry_points.txt formats. I find it
> always helps to focus on specifics - since the implementations can't be
> identical, what specifically are the differences that make you unhappy, and
> why do they make you unhappy? If some of those can be laid at distlib's
> door, fine - I think I'm generally quite responsive to specific issues raised.
> 
> Also, note that some features in an implementation might be useful to some
> people, even if not enshrined in a PEP. For example, distlib's wheel
> installation provides an option to install only the site-packages parts - no
> scripts or headers - a feature which you specifically requested, and which I
> readily added (as I can see its usefulness) without playing a "it's not in
> the PEP" card. Is that a "harmless innovation", or a "dangerous deviation
> from the standard"?

Nobody is saying that the only useful features are the ones enshrined in
a PEP.

> 
>> At the moment the wheel PEP is lagging a little behind some of the
>> ongoing discussions, in particular in terms of script generation. That's
>> fine, it's a work in progress. I hope it will be updated soon so that the
>> spec matches what's been agreed.
> 
> Well, let's not forget that distlib is a work in progress, too.
> 
>> But I think we have a reasonable consensus on how scripts should work,
> 
> Do we? Someone might tell me tomorrow that the "cool" one-executable
> solution I've recently implemented as an option on Windows (append shebang /
> archive to a stock executable) is an offence against all that's holy ;-)
> 
>> had a standard. I'm pretty unhappy that now we do have a standard, we
>> still have situations where a wheel generated by one tool can have
>> problems when installed with another - try "pip install wheel
>> --use-wheel" on Windows to see what I mean, the exe wrappers are missing
>> (this uses the wheel from PyPI, not a home-built one).
> 
> If distlib is proving to be a problem either as a producer or consumer of
> wheels, please raise issues.
> 
>> OK, so here's a concrete question for distutils-sig. If I want to use
>> wheels in my app (built them, install them, whatever) what should I use
>> as my "reference implementation". I don't want to implement the code
>> myself, I just want to produce lowest-common-denominator wheels that can
>> be used anywhere, and consume wheels that conform to the spec correctly.
>> This is not a hypothetical question - in the first instance I'm looking
>> to add support for loading setuptools/pip from wheels in virtualenv, and
>> I need to know what code to bundle to make that happen.
> 
> Some will say "wheel", even though it doesn't fully implement the spec,
> apparently because the wheel mount code (which,naturally, doesn't do
> anything unless it's called) is offensive to the point that some sort of
> fork is warranted ;-)

It has nothing to do with the Wheel mount code in particular. A reference
implantation is extremely useful but a reference implementation cannot
contain random features that somebody thought were useful or cool.

It's 100% absolutely and positively for *your* library to include features
not inside the spec. What that means is *your* library is not the reference
library that myself, Paul, and others thought it was trying to be. I do not
believe it's reasonable to expect the same library to be both innovator
and reference, the expectations and desires are just mutually exclusive.

Again there is absolutely nothing wrong with you experimenting in
distlib, it just means distlib isn't what I want to use right now.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130821/5e993529/attachment-0001.sig>