On May 9, 2014, at 4:20 PM, Terry Reedy wrote:
> On 5/9/2014 2:12 PM, Donald Stufft wrote:
>>
>> On May 9, 2014, at 1:28 PM, R. David Murray wrote:
>
>>> I don't understand this. Why it is our responsibility to provide a
>>> free service for a large project to repeatedly download a set of fi
On 5/9/2014 2:12 PM, Donald Stufft wrote:
On May 9, 2014, at 1:28 PM, R. David Murray wrote:
I don't understand this. Why it is our responsibility to provide a
free service for a large project to repeatedly download a set of files
they need? Why does it not make more sense for them to down
On May 9, 2014, at 1:28 PM, R. David Murray wrote:
> On Fri, 09 May 2014 11:39:02 -0400, Donald Stufft wrote:
>>
>> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
>>> On 09.05.2014 13:44, Donald Stufft wrote:
On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
>>> I snipped the rest of t
On Fri, 09 May 2014 11:39:02 -0400, Donald Stufft wrote:
>
> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
> > On 09.05.2014 13:44, Donald Stufft wrote:
> >> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
> > I snipped the rest of the discussion and reliability, using
> > unmaintained pack
Stefan,
If the only way you can think of to invalidate Donald's (vastly
superior) arguments is to accuse of him of "gossip", you should
probably reconsider your arguments. Looking at the conversation you
didn't actually link to
(https://botbot.me/freenode/python-requests/msg/14389415/) there is no
On May 9, 2014, at 12:11 PM, Stefan Krah wrote:
> Donald, I'm out of his discussion. I have one last request: please don't
> gossip about core devs in public as long as you have commit privs:
>
> https://botbot.me/freenode/python-requests/
I don’t really know how to respond to this. I was tal
On 09.05.2014 17:39, Donald Stufft wrote:
>
> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
>
>> On 09.05.2014 13:44, Donald Stufft wrote:
>>>
>>> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
Donald: I don't think anyone is arguing that hosting packages on
PyPI is a bad thing a
Donald, I'm out of his discussion. I have one last request: please don't
gossip about core devs in public as long as you have commit privs:
https://botbot.me/freenode/python-requests/
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
ht
On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
> On 09.05.2014 13:44, Donald Stufft wrote:
>>
>> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
>>> Donald: I don't think anyone is arguing that hosting packages on
>>> PyPI is a bad thing and PyPI as a service has gotten a lot better
>>> tha
On Fri, May 09, 2014 at 06:09:28AM -0700, Ethan Furman
wrote:
> On 05/08/2014 02:02 PM, Paul Moore wrote:
> Well, I do host a small handful of modules on PyPI, but I can say that some
> of my pain points are:
>
> - getting a good name: the obvious ones are taken, so the search
> begins to
On 09.05.2014 13:44, Donald Stufft wrote:
>
> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
>> Donald: I don't think anyone is arguing that hosting packages on
>> PyPI is a bad thing and PyPI as a service has gotten a lot better
>> than it was a few years ago.
>
> Didn’t mean to imply that I
On 05/08/2014 02:02 PM, Paul Moore wrote:
Socially, this change does not seem to be having the effect of
persuading more package developers to host on PyPI. The stick doesn't
appear to have worked, maybe we should be trying to find a carrot? Or
maybe we have to accept that some developers have s
On Fri, 9 May 2014 13:47:49 +0100
Paul Moore wrote:
> On 9 May 2014 13:25, Donald Stufft wrote:
> >> You're claiming that Mercurial moved to hosting on PyPI solely because
> >> users suddenly needed to add a flag to install from pip? As opposed to
> >> because PyPI gave them a more reliable hosti
On 9 May 2014 13:25, Donald Stufft wrote:
>> You're claiming that Mercurial moved to hosting on PyPI solely because
>> users suddenly needed to add a flag to install from pip? As opposed to
>> because PyPI gave them a more reliable hosting platform, for example?
>> OK. I certainly can't give any e
Paul Moore wrote:
> You're claiming that Mercurial moved to hosting on PyPI solely because
> users suddenly needed to add a flag to install from pip? As opposed to
> because PyPI gave them a more reliable hosting platform, for example?
> OK. I certainly can't give any evidence to dispute that clai
On May 9, 2014, at 8:21 AM, Paul Moore wrote:
> On 9 May 2014 13:06, Donald Stufft wrote:
I think it's important to point out that one of the driving factors that
caused
me to finally push for changes and what lead to PEP438 being created was
that
Mercurial's external
On 9 May 2014 13:06, Donald Stufft wrote:
>>> I think it's important to point out that one of the driving factors that
>>> caused
>>> me to finally push for changes and what lead to PEP438 being created was
>>> that
>>> Mercurial's external hosted was being extremely flaky. I can't remember the
On May 9, 2014, at 7:55 AM, Paul Moore wrote:
> On 9 May 2014 12:44, Donald Stufft wrote:
>> We still wouldn't be forcing anyone to upload things to PyPI. We are,
>> however,
>> discouraging people from not hosting on PyPI and providing incentives to
>> doing
>> that.
>
> But you're doing so
On 9 May 2014 21:55, Paul Moore wrote:
> On 9 May 2014 12:44, Donald Stufft wrote:
>> I think it's important to point out that one of the driving factors that
>> caused
>> me to finally push for changes and what lead to PEP438 being created was that
>> Mercurial's external hosted was being extre
On May 9, 2014, at 5:01 AM, Paul Moore wrote:
> On 9 May 2014 05:34, Donald Stufft wrote:
>> On May 8, 2014, at 5:22 PM, Donald Stufft wrote:
>>
Socially, this change does not seem to be having the effect of
persuading more package developers to host on PyPI. The stick doesn't
On 9 May 2014 12:44, Donald Stufft wrote:
> We still wouldn't be forcing anyone to upload things to PyPI. We are, however,
> discouraging people from not hosting on PyPI and providing incentives to doing
> that.
But you're doing so by inflicting pain on people using pip to install
those packages.
On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
> On 08.05.2014 23:22, Donald Stufft wrote:
>>
>>> On a personal note, I'm uncomfortable with the way this change is
>>> perceived as a case of *pip* enforcing a behaviour that the pip
>>> developers feel should be required. I actually don't like
Donald Stufft wrote:
> I?m unsure if you?re being willfully dense or if you?re just not understanding
> what I mean when I say ?almost?. Of course there are going to be a few
> outliers
> where people do bother to do that, but it?s not going to be common place at
> all.
I suggest that you confin
On 9 May 2014 05:34, Donald Stufft wrote:
> On May 8, 2014, at 5:22 PM, Donald Stufft wrote:
>
>>> Socially, this change does not seem to be having the effect of
>>> persuading more package developers to host on PyPI. The stick doesn't
>>> appear to have worked, maybe we should be trying to find
On 08.05.2014 23:22, Donald Stufft wrote:
>
>> On a personal note, I'm uncomfortable with the way this change is
>> perceived as a case of *pip* enforcing a behaviour that the pip
>> developers feel should be required. I actually don't like this change
>> particularly. So having pip implement the
On May 9, 2014, at 12:34 AM, Donald Stufft wrote:
> The data has finished processing, it represents a time diff of approximately
> one year. The pip release that caused all of this was released about 4-5
> months
> ago.
Oh I forgot to mention:
In order to make the comparison as accurate as po
On May 8, 2014, at 5:22 PM, Donald Stufft wrote:
>> Socially, this change does not seem to be having the effect of
>> persuading more package developers to host on PyPI. The stick doesn't
>> appear to have worked, maybe we should be trying to find a carrot?
>
> Do you have any data to point to
On 9 May 2014 08:22, "Donald Stufft" wrote:
>
>
> On May 8, 2014, at 6:20 PM, Nick Coghlan wrote:
>>
>> I actually need to follow up on that, because the terms *were* legally
questionable last time I looked (also too hard to review, since as far as I
am aware, they're only presented during new u
On May 8, 2014, at 6:20 PM, Nick Coghlan wrote:
>
> On 9 May 2014 07:23, "Donald Stufft" wrote:
> > On May 8, 2014, at 5:02 PM, Paul Moore wrote:
> >
> > > Or
> > > maybe we have to accept that some developers have sound reasons for
> > > not hosting on PyPI and work with them to find an acce
On 9 May 2014 07:23, "Donald Stufft" wrote:
> On May 8, 2014, at 5:02 PM, Paul Moore wrote:
>
> > Or
> > maybe we have to accept that some developers have sound reasons for
> > not hosting on PyPI and work with them to find an acceptable
> > compromise? Has anyone checked what Stefan's reasons ar
On May 8, 2014, at 5:02 PM, Paul Moore wrote:
> On 8 May 2014 16:46, Donald Stufft wrote:
>> Anything can be changes or reconsidered of course. I feel pretty strongly
>> that
>> an installer should not install things from places other than the index
>> without
>> a specific opt in. That discu
On 8 May 2014 16:46, Donald Stufft wrote:
> Anything can be changes or reconsidered of course. I feel pretty strongly that
> an installer should not install things from places other than the index
> without
> a specific opt in. That discussion would be best done on distutils-sig as it
> would req
On May 8, 2014, at 12:42 PM, R. David Murray wrote:
> On Thu, 08 May 2014 11:32:28 -0400, Donald Stufft wrote:
>> On May 8, 2014, at 11:21 AM, R. David Murray wrote:
>>> Ah, I understand now.
>>>
>>> Your perspective is as someone who is using pip for *deployment*.
>>
>> Deployment, or any k
On Thu, 08 May 2014 11:32:28 -0400, Donald Stufft wrote:
> On May 8, 2014, at 11:21 AM, R. David Murray wrote:
> > Ah, I understand now.
> >
> > Your perspective is as someone who is using pip for *deployment*.
>
> Deployment, or any kind of situation where you want to have a reproducible
> bui
On May 8, 2014, at 12:03 PM, Stefan Krah wrote:
> Donald Stufft wrote:
>> I said ?meaningful?. Almost nobody is going to ever bother googling it and
>> the likelihood that someone is able to MITM *you* specifically is far lesser
>> than the likelihood that someone is going to MITM one of the cd
Donald Stufft wrote:
> I said ?meaningful?. Almost nobody is going to ever bother googling it and
> the likelihood that someone is able to MITM *you* specifically is far lesser
> than the likelihood that someone is going to MITM one of the cdecimal users.
I'm doing this for important installs. --
On May 8, 2014, at 11:37 AM, M.-A. Lemburg wrote:
> On 08.05.2014 16:42, M.-A. Lemburg wrote:
>> On 08.05.2014 15:58, Donald Stufft wrote:
>>>
>>> On May 8, 2014, at 9:39 AM, M.-A. Lemburg wrote:
>>>
Well, to be fair and leaving aside uptime concerns and the general
desire to always
On May 8, 2014, at 11:34 AM, Stefan Krah wrote:
> Donald Stufft wrote:
>>> Today I've switched to manual install mode with manual sha256sum
>>> verification
>>> which is *far* safer than anything you get via pip right now.
>>
>> It is not safer in any meaingful way.
>>
>> If someone is in a
On 08.05.2014 16:42, M.-A. Lemburg wrote:
> On 08.05.2014 15:58, Donald Stufft wrote:
>>
>> On May 8, 2014, at 9:39 AM, M.-A. Lemburg wrote:
>>
>>> Well, to be fair and leaving aside uptime concerns and the general
>>> desire to always install packages from some server instead of
>>> a safe and tr
Donald Stufft wrote:
> > Today I've switched to manual install mode with manual sha256sum
> > verification
> > which is *far* safer than anything you get via pip right now.
>
> It is not safer in any meaingful way.
>
> If someone is in a position to compromise the integrity of PyPI's TLS, they
On May 8, 2014, at 11:21 AM, R. David Murray wrote:
> On Thu, 08 May 2014 10:37:15 -0400, Donald Stufft wrote:
>> Most users are not going to care up until the point where the external server
>> is unavailable, and then they care a whole lot. On the tin it sounds
>> reasonable
>> to just downl
On May 8, 2014, at 11:19 AM, Stefan Krah wrote:
> Donald Stufft wrote:
>> hosted packages are brittle and more prone to failure. Every single external
>> server adds *another* SPOF into any particular install set. Even if every
>> external server has a 99.9% uptime, when you combine multiple of
On Thu, 08 May 2014 10:37:15 -0400, Donald Stufft wrote:
> Most users are not going to care up until the point where the external server
> is unavailable, and then they care a whole lot. On the tin it sounds
> reasonable
> to just download the external file if the server is up however we've done
Donald Stufft wrote:
> hosted packages are brittle and more prone to failure. Every single external
> server adds *another* SPOF into any particular install set. Even if every
> external server has a 99.9% uptime, when you combine multiple of them the
> total
> uptime of any particular set of req
On 9 May 2014 00:52, "M.-A. Lemburg" wrote:
>
> On 08.05.2014 15:57, Nick Coghlan wrote:
>
> > (even the question of "does this software actually work?" is in our
> > sights if you consider a long enough time span). That's hard enough
> > with just a couple of service providers (Fastly and Rackspa
On May 8, 2014, at 10:36 AM, Stefan Krah wrote:
> Donald Stufft wrote:
>> There is support for trusted externally hosted packages, you put the URL in
>> PyPI and include a hash in the fragment like so:
>>
>> http://www.bytereef.org/software/mpdecimal/releases/cdecimal-2.3.tar.gz#md5=655f9fd72f
On 08.05.2014 15:57, Nick Coghlan wrote:
> On 8 May 2014 23:39, M.-A. Lemburg wrote:
>> However, for some reason there's a strong resistance against
>> doing this, which I frankly don't understand.
>
> Because we're taking responsibility for the end-to-end user experience
> of PyPI, and are expre
On 08.05.2014 15:58, Donald Stufft wrote:
>
> On May 8, 2014, at 9:39 AM, M.-A. Lemburg wrote:
>
>> Well, to be fair and leaving aside uptime concerns and the general
>> desire to always install packages from some server instead of
>> a safe and trusted local directory (probably too obvious ;-),
On May 8, 2014, at 10:31 AM, Antoine Pitrou wrote:
> On Thu, 08 May 2014 10:21:34 -0400
> "R. David Murray" wrote:
>>>
>>> "unreliable" reads as "not safe", ie: insecure.
>>>
>>> You probably want something like "and access to it may be unreliable".
>>
>> Actually, thinking about this some m
Donald Stufft wrote:
> There is support for trusted externally hosted packages, you put the URL in
> PyPI and include a hash in the fragment like so:
>
> http://www.bytereef.org/software/mpdecimal/releases/cdecimal-2.3.tar.gz#md5=655f9fd72f7a21688f903900ebea6f56
That is exactly the mode I was us
On May 8, 2014, at 10:21 AM, R. David Murray wrote:
> On Thu, 08 May 2014 10:11:39 -0400, "R. David Murray"
> wrote:
>> On Thu, 08 May 2014 09:58:08 -0400, Donald Stufft wrote:
>>> I don't think the warning is FUD, and it doesn't mention anything security
>>> related at all. The exact text of
On Thu, 08 May 2014 10:21:34 -0400
"R. David Murray" wrote:
> >
> > "unreliable" reads as "not safe", ie: insecure.
> >
> > You probably want something like "and access to it may be unreliable".
>
> Actually, thinking about this some more, *most* end-users aren't going
> to care that there's an
On Thu, 08 May 2014 10:11:39 -0400, "R. David Murray"
wrote:
> On Thu, 08 May 2014 09:58:08 -0400, Donald Stufft wrote:
> > I don't think the warning is FUD, and it doesn't mention anything security
> > related at all. The exact text of the warning is in the subject of the email
> > here:
> >
>
On May 8, 2014, at 10:11 AM, R. David Murray wrote:
> On Thu, 08 May 2014 09:58:08 -0400, Donald Stufft wrote:
>> I don't think the warning is FUD, and it doesn't mention anything security
>> related at all. The exact text of the warning is in the subject of the email
>> here:
>>
>>cdecima
On Thu, 08 May 2014 09:58:08 -0400, Donald Stufft wrote:
> I don't think the warning is FUD, and it doesn't mention anything security
> related at all. The exact text of the warning is in the subject of the email
> here:
>
> cdecimal an externally hosted file and may be unreliable
>
> Which
On May 8, 2014, at 9:58 AM, Donald Stufft wrote:
> Now this does not mean that ``pip install cdecimal`` will automatically
> install
> this, because whether or not you're willing to install from servers other than
> PyPI[1] is a policy decision for the end user of pip.
I forgot to add, for ext
On May 8, 2014, at 9:39 AM, M.-A. Lemburg wrote:
> Well, to be fair and leaving aside uptime concerns and the general
> desire to always install packages from some server instead of
> a safe and trusted local directory (probably too obvious ;-),
> it would certainly be possible to add support fo
On 8 May 2014 23:39, M.-A. Lemburg wrote:
> However, for some reason there's a strong resistance against
> doing this, which I frankly don't understand.
Because we're taking responsibility for the end-to-end user experience
of PyPI, and are expressly trying to eliminate the elements of that
user
On Thu, May 8, 2014 at 11:39 PM, M.-A. Lemburg wrote:
> I agree with Stefan that the warning message wording is less
> than ideal. You'd normally call such blanket statements FUD,
> esp. since there are plenty external hosting services which
> are reliable and safe to use.
No, it's not FUD. Every
Well, to be fair and leaving aside uptime concerns and the general
desire to always install packages from some server instead of
a safe and trusted local directory (probably too obvious ;-),
it would certainly be possible to add support for
trusted externally hosted packages.
However, for some rea
On May 8, 2014, at 8:12 AM, Stefan Krah wrote:
> Victor Stinner wrote:
>> I don't understand your email. Can you please elaborate?
>
> There is nothing wrong with the package. The remark is a joke provoked by
> a long history of a campaign [1] against external packages on distutils-sig.
>
>
Victor Stinner wrote:
> I don't understand your email. Can you please elaborate?
There is nothing wrong with the package. The remark is a joke provoked by
a long history of a campaign [1] against external packages on distutils-sig.
Many tools (like crate.io, when it was still up) have made dero
Hi,
I don't understand your email. Can you please elaborate?
Victor
2014-05-06 23:35 GMT+02:00 Stefan Krah :
> Just a warning, in case any of the new packaging team forgot to contact
> http://cve.mitre.org/ .
>
>
> Stefan Krah
>
>
>
> ___
> Python-Dev
Just a warning, in case any of the new packaging team forgot to contact
http://cve.mitre.org/ .
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
64 matches
Mail list logo
