On 21 August 2013 11:56, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
But I think we have a reasonable consensus on how scripts should work,
Do we?
To the level of "wheels builders should write metadata that defines the scripts and wheel installers should generate the necessary wrappers" then yes. We may or may not (depending on your viewpoint) have agreement on the format of that metadata. Personally, I think that Metadata 2.0 where the wheel uses that format, and entry-points.txt for older versions, is the only realistic option here. I would like to see some clarity on the status of the wheel 1.0 spec. Where there are areas like this where the spec is either silent or missing sufficient detail to allow us to implement a common approach, should we be updating the 1.0 spec or should we be creating a 1.1 spec (I'd prefer the former)? Who does those updates? Must they go through Daniel as the author (who's been quite quiet, possibly he's hiding somewhere rather than being drawn into the fray :-))?
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 ;-)
That won't be me. I'm more interested in discussions about interoperability issues than about how the functionality gets implemented.
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.
I don't believe that distlib creates scripts based on entry-points.txt for pre-2.0 metadata. I have raised an issue for that. That's the only significant issue I have with distlib from the POV of what it can solve. There may be other interoperability issues where other tools can't consume things that distlib produces - I haven't tested anything like all of the combinations. We currently have 2 producers and 3 consumers. That's already 6 interactions to test. And if there *is* an issue, it's not always at all clear who to report the problem to. I'm not complaining about *any* of the implementations here. And I apologise if you in particular feel "picked on" (there's probably a distutils-sig "victim of the week" rota somewhere for this ;-)) My real concern is that we're drifting away from standards-based design towards implementation-based. And I think that updating the wheel PEP to be tighter on some of the details is what's really needed (hey, look, it's Daniel's turn to be picked on! :-)) I'd be willing to author an updated version of the wheel spec if all of the interested parties are OK with that (in particular, Nick and Daniel). If nothing else, that means that everyone can pick on me so I wouldn't feel quite so much like a troublemaker :-) Paul PS I really, really don't want anyone here to feel like anything they do is not valued. This is about tidying up the documentation, not about stifling anyone's enthusiasm or blocking any experimentation.