> On Oct 3, 2014, at 4:06 AM, holger krekel <[email protected]> wrote: > > Hi Donald, > > i could just only briefly glimpse over the new draft. I am still not in > favor of the PEP because it forces backard-incompatible changes and work > on various sides for not enough gain. Particularly end users will see > previously working commands now fail and if they run a new enough pip > version they get a hint on how to manually fix it. > > In the longer term you argue that people will appreciate reusing the concept > of dealing with multiple repositories as known with Linux Distros. > And that PEP470 would eventually simplify the user interface of pip and > the implementation of pypi a bit. > > I'll see next week if i can come up with suggestions how to reduce friction > introduced by the PEP while maintaining the benefits. And probably with > a few questions because i didn't understand all details yet i think.
Mostly I think that the current situation is the worst possible implementation of handling offsite hosting that I can think of. I don't believe any person would design this system from scratch and the only reason it exists is because of lots of small decisions over the course of history. I think that the current implementation does a disservice to everyone involved. I think that it hurts end users because they end up most likely insecure, with tooling that cannot accurately report errors, and a horrible user interface. I think that it hurts authors, even those that want to rely on this feature, because it positions them in a case where it either implicitly breaks the expectations of end users who view PyPI mainly as a repository or it explicitly causes them pain in attempting to use and decipher the flags. It has been suggested that the changes pip made in implementing PEP 438 was done in an attempt to make not hosting on PyPI so painful that authors would be forced to host on PyPI. I think that backwards compatability is important, however I also think that it's important to break backwards compatability when it makes sense to do so. The current situation is such that attempting to preserve backwards compatability has made things worse for everyone involved whenever a project wishes to do anything but host their projects on PyPI. As far as simplication goes, I don't believe it simplifies the implementation of PyPI at all, it just shuffles things around and creates work on my part in order to get PyPI supporting the new stuff. It does however let installers become simpler and it enables installers to present accurate error information that actually helps determine the root cause of a failure instead of the current silent failure with a confusing error message model. I look forward to your suggestions, but I'm not hopeful. I've been thus far unable to determine a way to improve the current solution in a way that isn't just papering over one problem without solving the fundamental issue. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
