On Thu, 20 Sep 2018 at 08:01, Tzu-ping Chung <uranu...@gmail.com> wrote: > I’m afraid the new implementation will still need to deal with compatibility > issues. > Users expect Pipenv to work exactly as pip, and get very angry if it does not, > especially when they see it is under the PyPA organisation on GitHub. The last > time Pipenv tries to explain it does whatever arbitrary things it does, we get > labelled as “toxic” (there are other issues in play, but this is IMO the > ultimate > cause). Whether the image is fair or not, I would most definitely want to > avoid > similar incidents from happening again.
IMO, the only way to address that is by defining standards for the behaviour. Having a standard document to point to that says "this is what's been agreed in public debate" gives both pipenv and pip a solid basis to explain why we do what we do. There will likely be corner cases where the details are implementation dependent, but again, the fact that the standard doesn't mandate behaviour is the best argument you're going to get for that. There will always be people that complain if you're not 100% bug-for-bug compatible with pip, but that's life. Obviously, any standard will have to look at pip's behaviour as a starting point (simply because pip's been around as the only implementation for so long). But simplifying and cutting out some of the cruft is part of any standards process, so it's perfectly OK to mark certain parts of what pip does now as "implementation defined" or "needs to change". Also, Dan said: > Since you mentioned following along, here's what we're working on right now: The problem here is the same - without some sort of agreement (in the form of a documented standard[1]) that what those libraries do is "the right behaviour", it's not clear how pip can switch to using them. And promises that they "do the same as pip does" are not likely to work, for precisely the reasons Tzu-ping noted above (there's always someone that will pick up on any discrepancy, no mater how small). Paul PS While I don't have much time for people standing on the sidelines and telling us what we "should" do, I do think that by putting projects under the PyPA banner, we assume a responsibility for making sure we behave consistently, whether we like it or not. Interop standards documents have been how we've discharged that responsibility so far, but pipenv has such a strong overlap with pip that it opens up a lot of areas where we haven't even thought about standards yet. Managing expectations while we get things in line is not a pleasant task, but it's one we need to do. [1] I'm at least as sick of saying "standard" as you are of hearing it. Take it to mean "everyone's agreed and anyone likely to complain afterwards has had an opportunity to speak up, and there's a record" - I'm not wedded to any particular process here. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/IPS7PDROXEY2I353A6MURRSP2KWOIB3N/
