[Catalog-sig] pre-PEP: transition to release-file hosting at pypi site

PJ Eby pje at telecommunity.com
Mon Mar 11 07:09:16 CET 2013

On Sun, Mar 10, 2013 at 8:25 PM, Donald Stufft <donald at stufft.io> wrote:
> I don't think anyone is bad here, nor am I arguing against any particular person or group of people. I'm arguing against a practice and a system. You're going out of your way to find excuses to throw all sorts of stop energy here.

Calling a legitimate disagreement with your point of view "stop
energy" seems inappropriate to me, since my issue is with you
derailing the topic of how to get people to *voluntarily* migrate to a
better situation than the present one, and to develop tools for that
process.  The only thing I wish you to stop is the repeated assertion
without proof that 1) external links must go *and* 2) this must be an
enforced directive rather than a (highly-encouraged) option.

I have even gone so far as to suggest, earlier in this thread, what
evidence I would find at least suggestive of your POV.  But your
response to that and prior challenges to those assertions, has been
simply to move your goalpost.  E.g. from "current uptime is bad" to
"any uptime lower than PyPI's is totally unacceptable".

I, on the other hand, have moved in the direction of *your* proposals
repeatedly, making adjustments as I find actually-convincing evidence
and/or reasoning, or find ways to deal with the issues.  I have
compromised quite a bit.  (And have already spent a fair amount of
time writing setuptools code to lay a foundation for these changes.)

You, as far as I can tell, have not moved your position in the slightest.

Which of these is "stop energy"?

It is not the case that external links must be removed from PyPI in
order to ensure security, or uptime.  And it is *especially* not the
case that you are the BDFL of uptime.  You're definitely not the BDFL
of uptime for any given project hosted on PyPI, that you *voluntarily
choose* to make a part of your build process.  If your primary
argument is that project X must host its files on PyPI because of your
build process, then I think you misunderstand open source, and also
the part where you *chose* to make it part of your build process.  It
certainly doesn't give you the right to force projects Y, Z, and Q --
that you don't even use! -- to also host their projects on PyPI,
because project X -- the one you do use -- has a slow or unreliable
file host!

It seems disingenuous to then shfit the argument back to security when
challenged on uptime, and back to uptime when challenged on security.
We've looped back and forth over those for some time: when I point out
that wheels have signatures which will make off-site hosting
relatively unimportant to the security picture, you jump back to
talking about uptime.  When I point out that uptime is a consensual
factor that in no way justifies legislating what other people can do
with their projects, you go back to talking about security.

Make up your mind.  What problem are you actually trying to solve?

(I expect your response on wheels to be that wheels aren't there yet,
etc., but that isn't actually a response to the objection unless
you're going to change your position to, "okay, external links to file
formats that can be signed can stay," or something of that sort.
Otherwise, you're not actually compromising, just using the fact that
wheels aren't in common use yet as an argument to keep the position
you started with.)

> My analogy served only to put into light that the system that I'm trying to change is insecure, just like allowing anyone to walk into a bank vault and pick up money would be insecure. I fully believe that the people using such a system are completely trustworthy people. But just because *they* are trustworthy doesn't mean that a system which allows *anyone* to attack other Python developers is *ok*.

And my analogy served only to put into light the part where you're
insisting that one group of people change for the benefit of a group
which is already benefiting from their pre-existing generosity.

That being said, I do see that I could have misinterpreted the intent
of your analogy -- it sounded like you were saying that the developers
who host off-PyPI were thieves walking into your bank and taking your
money (i.e., analogizing theft with inconveniencing you by making your
builds fail or run slowly).

Though to be honest, I still don't comprehend how else to make any
kind of sense to that analogy in its original context.  Who is the
bank?  Whose money is being taken?  The whole thing is utterly
confusing to me if I try to take it any other way than the way I did,
because it doesn't seem to have any other simple 1:1 mapping to the
situation, as far as I can see.   Your explanation seems terribly
abstract and tortured to me, as far as analogies go.

> When discussing security of a system it's necessary to divorce yourself from the implementations of things. When you get wrapped up in the implementation you turn things into a Us vs Them game (as evidenced by several of your messages) instead of discussing the merits of the various systems and which ones serve the greatest needs of the community the best.

I think you've got things backwards here.  It's you who's been arguing
that the solution to the problem of "improved uptime and security" is
best implemented by "ban all non-PyPI hosting".  It is I who has been
arguing that this is a premature judgment and rush to implementation,
without considering all of the design angles.  And I am the one asking
you to stop insisting on this one implementation and state your
*actual* problem with external links.

(By which I mean, a problem stated such that, if you're given a
solution that *doesn't* involve banning them from PyPI, you aren't
going to rejigger the problem statement so that it once again requires
banning.  That's moving the goalposts, and that's what keeps happening
in this discussion, at least as far as I can see.  I, on the other
hand, have given you my actual problem with your proposal, and I have
not moved *my* goalposts.  Instead, I've moved towards your position,
more than once.  But I've moved as far towards it as I can go at this
time, without you providing any additional evidence or explanation or
*some* kind of engagement with the points that I've raised above that
you've previously ignored, in this thread and others.)

More information about the Catalog-SIG mailing list