[Distutils] PEP 470, round 4 - Using Multi Repository Support for External to PyPI Package File Hosting

Donald Stufft donald at stufft.io
Fri Oct 3 14:02:05 CEST 2014


> On Oct 3, 2014, at 4:06 AM, holger krekel <holger at merlinux.eu> 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



More information about the Distutils-SIG mailing list