[Distutils] How to handle launcher script importability?

[Daniel Holth]

On Wed, Aug 21, 2013 at 8:01 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 August 2013 12:22, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>>
>> Paul Moore <p.f.moore <at> gmail.com> writes:
>>
>> > Another one IIRC was that distlib didn't put entry-points.txt in the
>> > .dist-info directory in the wheel (which breaks entry points). I think
>> > that's fixed now (and again, the Wheel spec is silent on what is correct
>> > behaviour here).
>>
>> Right. The recent PEP 426 updates with the "commands" key supersedes the
>> entry points stuff, so I'm not sure what exactly should be done here. The
>> distlib code uses the latest PEP information. Since wheel is moving to
>> pydist.json, I assume that (when it gets around to it) it will have the
>> relevant scripts info in pydist.json, so I haven't implemented using
>> scripts
>> declared in entry_points.txt in distlib for that reason.
>
>
> OK, I see what you're saying here. But the Wheel 1.0 spec says that metadata
> is in the METADATA file (and comes from PKG-INFO). So my reading of that
> means that Metadata 1.x will remain valid for the foreseeable future (sure,
> Metadata 2.0 may become acceptable *as well* but the point of having a Wheel
> 1.0 spec is that we won't stop supporting it for some time yet). So you need
> to have a pre-2.0 solution in place, and while entry-points.txt isn't
> explicitly stated in the wheel PEP, it's the obvious equivalent.
>
> If you want to say distlib won't support pre-Metadata 2.0 specifications of
> script metadata, then that's your choice - it's not contrary to the
> standards but I'd view it as a quality of implementation choice. I view the
> underspecification in the Wheel 1.0 spec as similarly a quality of detail
> issue, and I'd expect to fix it in either an update to Wheel 1.0, or a Wheel
> 1.1 which does not make the jump to pure Metadata 2.0.
>
> Paul

The wheel spec should probably say that its .dist-info directory
should conform to a .dist-info PEP rather than saying it contains any
particular files like METADATA. The only files that belong to wheel
itself are the manifest and the WHEEL file that contains the version
of the wheel format itself. Before the (useful) scripts wrapper
feature, the wheel installer did not need to look at the PEP 426 or
setuptools metadata at all. You can install them with unzip.

The wheel command line tool lately has a "wheel install-scripts
[package]" command that uses setuptools to rewrite entry-points script
wrappers for an installed package. It is a proof of concept but it
comes in handy. When pip is updated to be able to generate script
wrappers at install time then a simultaneously released bdist_wheel
will be able to update its default behavior to defer script generation
and produce the newer metadata. In the meantime scripts are imperfect.

Egg's controversial features like being a valid sys.path entry were
not really left out of wheel. The format could have been a .tar file
after all. Instead, wheel's documentation emphasizes what turned out
to be the least problematic use pattern as an installation format. Egg
got there from the other direction starting as a plugin container.