[Distutils] How to handle launcher script importability?

[Donald Stufft]

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

> Donald Stufft <donald <at> stufft.io> writes:
> 
>> I think you're using a completely different definition of "reference
>> implementation" than I've ever seen used. A reference implementation
> 
> Quite possibly, but I feel justified in this case ... I'll say why below.
> 
>> by definition cannot contain customizations or additions or extensions
>> from the spec. The entire *point* of a reference implementation is to
>> act as programatic reference to the spec. Something being the reference
>> implementation does not speak to the quality of the implementation and
>> as such it may not be the *best* implementation.
> 
> The packaging PEPs don't do down to programmatic detail in their 
> specification. In the stricter definition of "reference implementation" (RI) 
> you're talking about, a spec comes with a reference implementation but also a 
> test suite (provided by the spec author) which conforming 
> implementations must pass. While this is de rigueur in the Java world, it's 
> not common in the Python world. Without such a test conformance suite, I 
> think it's reasonable to use the looser definition of RI that I did.
> 
>> An example is the wsgiref from the standard library. Very few projects
>> actively use wsgiref for much at all if they use it at all. However it's
>> existence means that web servers like gunicorn, mod_wsgi etc can simply
>> test against it instead of needing to test against every implementation
>> of WSGI.
> 
> While you can certainly use wsgiref for interoperability testing (much as I 
> use wheel's wheel implementation for interoperability testing with distlib) I 
> don't think WSGI implementations run a suite of tests provided in wsgiref 
> before claiming conformance. I'm happy to be corrected 
> if I'm wrong about that :-)

I have no idea what the WSGI servers actually do, it was just an example.

> 
> In my experience of implementing PEPs (282, 391, 397, 405) all 
> implementations have had test suites, but none have had the tests implemented 
> by any central authority. In discussions the relevant implementations have 
> been referred to as RIs and that's the way I'm using it now.

None of those peps are defining a standard with a primary goal of being
able to be completely replaced by a different module and still work. They
are for adding a single implementation to the standard library. So it would
make sense for those not to have a reference implementation because there
are not any expected other implementations besides the one that got
added to the stdlib.

> 
>> Which implementation is used (and ultimately possibly enshrined in the
>> standard library) is decided through merit. Which implementation is
>> used as the reference implementation is typically decided by the standards
>> body (in this case, distutils-sig or Nick or whoever). 
> 
> If Nick or whoever is planning to write a test suite which all 
> implementations must pass, great. But that would (I suppose) mean tying 
> things down to a specific Python interface at the module, class and function 
> level - not something I've seen imposed externally before. But in 
> the absence of such, I don't see any problem with my interpretation of RI, 
> since the stricter interpretation only makes sense in the presence of 
> accompanying tests generated by the spec originators.

I would expect that the reference implementation would include acceptance
tests that test the various specs yes. For Wheel this wouldn't (in my mind)
be at the Python level (so it wouldn't encode a particular python level API)
other than a very minimal interface (which may simply be a CLI script?)
needed to actually power the testing but the primary use of the acceptance
tests would be to verify that the implementation can create and install
Wheel files to the spec. It's purpose would not be to set a specific Pythonic
API as the spec because the spec is defining a file format not a Python API.

Not having behavior defined by an implementation is very important to me,
hence why I'm being such a stickler for wanting something that other tools
can use to test against.

-----------------
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/e49c5508/attachment.sig>