On May 15, 2014, at 8:53 AM, Paul Moore wrote:
> This has always been a major difficulty with the PEP process, and any
> similar consensus approach - the huge majority of users simply aren't
> active in "the community". And furthermore, it's very hard to get
> feedback from people who agree with
On 15 May 2014 22:05, "Stefan Krah" wrote:
>
> Nick Coghlan wrote:
> > > > I understand you think that is the purpose of PyPI, but I'm trying
to
> > > > tell you that the people that work on PyPI and pip do not share this
> > > > opinion, and as such it can be considered incorrect.
> > >
> > > If
On 15 May 2014 12:38, Stefan Krah wrote:
>> While the opinions of core developers do matter, we're also far from being
>> representative of the wider Python community
>
> It's not only about core developers. The main point is that it's very hard to
> determine any general opinion of Python users.
Nick Coghlan wrote:
> > > I understand you think that is the purpose of PyPI, but I'm trying to
> > > tell you that the people that work on PyPI and pip do not share this
> > > opinion, and as such it can be considered incorrect.
> >
> > If only the opinions of the persons working on PyPI and pip
On 15 May 2014 20:44, "Stefan Krah" wrote:
>
> Noah Kantrowitz wrote:
> > > Coming back to PyPI: Its main purpose is having a central place to
> > > register, search for and find packages. It doesn't matter where the
> > > distribution files are hosted, as long as the installers can find
them.
>
Noah Kantrowitz wrote:
> > Coming back to PyPI: Its main purpose is having a central place to
> > register, search for and find packages. It doesn't matter where the
> > distribution files are hosted, as long as the installers can find them.
>
> I understand you think that is the purpose of PyPI,
Noah Kantrowitz wrote:
> Sorry, going to have to stop you here. This, and all your conclusions based
> on this assumption, are flat out incorrect. You are far far far in the
> minority of people that think this is what PyPI is.
The vast majority of Python users does not blog, is not on mailing li
On my phone so I can't respond to everything here but I just want to say I
don't think a discussion where we can't challenge each other's conclusions
isn't going to go anywhere. Hopefully we are adults and can handle
disagreement.
> On May 14, 2014, at 4:26 PM, "M.-A. Lemburg" wrote:
>
> Noa
On May 14, 2014, at 1:26 PM, "M.-A. Lemburg" wrote:
> On 14.05.2014 21:48, Noah Kantrowitz wrote:
>>
>> On May 14, 2014, at 12:44 PM, "M.-A. Lemburg" wrote:
>>
>>> PyPI is still mainly the Python registry for mapping package
>>> names to URLs and descriptions.
>>
>> Sorry, going to have to s
On 14.05.2014 21:48, Noah Kantrowitz wrote:
>
> On May 14, 2014, at 12:44 PM, "M.-A. Lemburg" wrote:
>
>> PyPI is still mainly the Python registry for mapping package
>> names to URLs and descriptions.
>
> Sorry, going to have to stop you here. This, and all your conclusions based
> on this as
On May 14, 2014, at 12:44 PM, "M.-A. Lemburg" wrote:
> PyPI is still mainly the Python registry for mapping package
> names to URLs and descriptions.
Sorry, going to have to stop you here. This, and all your conclusions based on
this assumption, are flat out incorrect. You are far far far in t
On 13.05.2014 13:46, Donald Stufft wrote:
>
> On May 13, 2014, at 7:16 AM, Stefan Krah wrote:
>
>> FreeBSD ports have been using the download-from-many-but-verify strategy
>> for a long time. I don't see why users should find this surprising.
>
> The difference is in expectations which is a fu
Paul Moore wrote:
> 1. There will be a single per-package opt-in flag, that is needed for
> any package not hosted on PyPI (effectively merging --allow-external
> and --allow-unverifiable)
Could this flag be called "--skip-verify"? If I understand correctly,
it will also suppress verification fo
On May 13, 2014, at 8:16 AM, Paul Moore wrote:
>> External and verifiable packages have the same security as uploaded files
>> (though I would like to use sha256 instead of md5 the URL).
>
> Correct (I think it might even be correct for indirectly linked files
> where each link has a hash, whic
On 13 May 2014 12:16, Stefan Krah wrote:
>> I believe that option has been there for a while as
>> --allow-[all]-external. Again, naming and discoverability may be an
>> issue, but the functionality is available.
>
> Yes, but I understood that the latest proposals in this thread wanted
> to get ri
On May 13, 2014, at 7:58 AM, Stefan Krah wrote:
> Paul Moore wrote:
>>> Not quite the sequence of events. -- I left the existing explicit link
>>> for some time after the first posts to python-dev. Then serious security
>>> issues were marginalized ("not a meaningful scenario"). I find this a
Paul Moore wrote:
> > Not quite the sequence of events. -- I left the existing explicit link
> > for some time after the first posts to python-dev. Then serious security
> > issues were marginalized ("not a meaningful scenario"). I find this a
> > little surprising, since PEP 458 is precisely th
On May 13, 2014, at 7:16 AM, Stefan Krah wrote:
> FreeBSD ports have been using the download-from-many-but-verify strategy
> for a long time. I don't see why users should find this surprising.
The difference is in expectations which is a function of what the “normal” is.
For FreeBSD ports it
Paul Moore wrote:
> > "Installers should provide a blanket option to allow installing any
> > verifiable
> > external link."
> >
> > Perhaps something like --allow-verifiable-external would do? I would not be
> > unhappy if link-spidering were to be removed, I find it reasonable to
> > provide
On 12 May 2014 16:57, Stefan Krah wrote:
> Thank you for your measured responses, and I agree with you that pip should
> follow PEP 438. The main argument on python-dev was about *editorializing*
> the contents of the PEP in both pip warning messages and posts to the mailing
> lists (and by that
[This is not a response to anything that Nick wrote. -- I don't have the
rest of the thread, so unfortunately I've to paste from the archive.]
Paul:
> I'll give up the fight at this point. I don't know this part of the
> pip code well enough to offer a patch implementing my suggestion, and
> in
On 12 May 2014 21:34, M.-A. Lemburg wrote:
> Think about it: PyPI has become a great hosting platform in the last
> year, it's attractive to host packages on the platform and this also
> shows in the number of package authors that have decided to switch
> over to PyPI for hosting.
>
> The ones tha
Given the thread on python-dev and comments I have read elsewhere,
I would like to remind everyone in this discussion to come back to
a respectful attitude towards the issues being discussed and the
people involved.
I am writing this as Python core developer and as PSF board member.
PyPI is run by
23 matches
Mail list logo
