I wish there was a way to automatically redirect people requesting PIL to
get Pillow instead. It's a PYPI/setuptools friendly repackaging of PIL that
has been going on for years now:
https://pypi.python.org/pypi/Pillow/2.4.0
On 19 May 2014 23:29, Donald Stufft wrote:
> Just an update, asyncmon
Just an update, asyncmongo has released to PyPI now, so I’ve removed
them from the gists as well. Still no word back from PIL.
On May 18, 2014, at 11:21 AM, Donald Stufft wrote:
>
> On May 18, 2014, at 2:20 AM, holger krekel wrote:
>
>> On Sat, May 17, 2014 at 20:20 -0400, Donald Stufft wrote
On May 18, 2014, at 2:20 AM, holger krekel wrote:
> On Sat, May 17, 2014 at 20:20 -0400, Donald Stufft wrote:
>> On May 17, 2014, at 1:51 PM, holger krekel wrote:
>>
>>> On Sat, May 17, 2014 at 11:32 -0400, Donald Stufft wrote:
More conclusions!
In that same time period PyPI re
On Sat, May 17, 2014 at 20:20 -0400, Donald Stufft wrote:
> On May 17, 2014, at 1:51 PM, holger krekel wrote:
>
> > On Sat, May 17, 2014 at 11:32 -0400, Donald Stufft wrote:
> >> More conclusions!
> >>
> >> In that same time period PyPI received a total of ~16463209 hits to a page
> >> on
> >>
On May 17, 2014, at 1:51 PM, holger krekel wrote:
> On Sat, May 17, 2014 at 11:32 -0400, Donald Stufft wrote:
>> More conclusions!
>>
>> In that same time period PyPI received a total of ~16463209 hits to a page on
>> the simple installer API. This means that in total these projects represent
>
On Sat, May 17, 2014 at 11:32 -0400, Donald Stufft wrote:
> More conclusions!
>
> In that same time period PyPI received a total of ~16463209 hits to a page on
> the simple installer API. This means that in total these projects represent
> a combined 0.56% of the simple installer traffic on PyPI.
More conclusions!
In that same time period PyPI received a total of ~16463209 hits to a page on
the simple installer API. This means that in total these projects represent
a combined 0.56% of the simple installer traffic on PyPI. However looking at
the numbers you can see that PIL is an obvious ou
Ok, numbers updated with better processing that looks right this time. I still
believe it holds up to the conclusions I said earlier.
https://gist.github.com/dstufft/5ebfb0d7e53194e5f89e
On May 17, 2014, at 10:33 AM, Donald Stufft wrote:
>
> On May 17, 2014, at 10:21 AM, Donald Stufft wrote:
On May 17, 2014, at 10:21 AM, Donald Stufft wrote:
>
> On May 16, 2014, at 3:27 PM, Carl Meyer wrote:
>
Basically, I think some acknowledgment of this problem of packages
without active maintainers (and ideally a proposed solution to it)
should be in PEP 470.
>>>
>>> Right now
On May 17, 2014, at 1:36 AM, Nick Coghlan wrote:
> On 16 May 2014 21:20, Donald Stufft wrote:
>> However that being said, a significant portion of that 7% has only a few
>> (sometimes only 1) old releases hosted externally. Often times when I've
>> pointed this out to authors they didn't even r
On May 16, 2014, at 3:27 PM, Carl Meyer wrote:
>>> Basically, I think some acknowledgment of this problem of packages
>>> without active maintainers (and ideally a proposed solution to it)
>>> should be in PEP 470.
>>
>> Right now the PEP's (and my) position is that it breaks because I believe
On 16 May 2014 21:20, Donald Stufft wrote:
> However that being said, a significant portion of that 7% has only a few
> (sometimes only 1) old releases hosted externally. Often times when I've
> pointed this out to authors they didn't even realize it and they had just
> forgotten to call ``setup.p
On May 16, 2014, at 5:56 PM, Paul Moore wrote:
> On 16 May 2014 22:12, Stefan Krah wrote:
>> Paul Moore wrote:
>>> [1] I'm assuming that we don't have any cases where authors of
>>> maintained packages hosted outside of PyPI refuse to set up an index
>>> page. There's no technical reason why t
On 16 May 2014 22:12, Stefan Krah wrote:
> Paul Moore wrote:
>> [1] I'm assuming that we don't have any cases where authors of
>> maintained packages hosted outside of PyPI refuse to set up an index
>> page. There's no technical reason why they should do so, but there
>> remains the possibility o
On 16 May 2014 22:13, Carl Meyer wrote:
> The question is _who_ tells them about this external index (or multiple
> external indices, one per project), how, and when. It's not like we can
> just post about it on distutils-sig and assume that every user of a
> legacy project will find out about it
On 05/16/2014 04:00 PM, Paul Moore wrote:
> On 16 May 2014 20:27, Carl Meyer wrote:
Or, thirdly, Paul's proposal could solve this, if PyPI automatically
generated an "external legacy index" for any packages that haven't
generated their own external index URL by a certain date. Reall
Paul Moore wrote:
> [1] I'm assuming that we don't have any cases where authors of
> maintained packages hosted outside of PyPI refuse to set up an index
> page. There's no technical reason why they should do so, but there
> remains the possibility of non-technical issues that need to be
> thrashe
On 16 May 2014 20:27, Carl Meyer wrote:
>>> Or, thirdly, Paul's proposal could solve this, if PyPI automatically
>>> generated an "external legacy index" for any packages that haven't
>>> generated their own external index URL by a certain date. Really in a
>>> way this is similar to Holger's prop
On Fri, May 16, 2014 at 07:12:01PM +, holger krekel wrote:
> On Fri, May 16, 2014 at 13:38 -0500, Carl Meyer wrote:
> > One option is Holger's solution: scraping the current links and
> > populating them as verified external links. We both don't like this
> > because it involves PyPI misleading
On May 16, 2014, at 3:27 PM, Carl Meyer wrote:
> On 05/16/2014 02:15 PM, Donald Stufft wrote:
>>> I guess the key thing I don't understand yet is, why would we assume
>>> that any package that hasn't already switched to verified-external-links
>>> since PEP 438, given a one-year window so far to
On 05/16/2014 02:15 PM, Donald Stufft wrote:
>> I guess the key thing I don't understand yet is, why would we assume
>> that any package that hasn't already switched to verified-external-links
>> since PEP 438, given a one-year window so far to do so, is any more
>> likely to populate this new disc
On May 16, 2014, at 3:12 PM, holger krekel wrote:
> On Fri, May 16, 2014 at 13:38 -0500, Carl Meyer wrote:
>> On 05/16/2014 12:10 PM, Donald Stufft wrote:
2. Add a deprecation path for --allow-unverified; can describe it in
general terms as "the PEP 438 installer flag allowing installa
On May 16, 2014, at 2:38 PM, Carl Meyer wrote:
> On 05/16/2014 12:10 PM, Donald Stufft wrote:
>>> 2. Add a deprecation path for --allow-unverified; can describe it in
>>> general terms as "the PEP 438 installer flag allowing installation of
>>> unverified external packages" if you don't want to
On Fri, May 16, 2014 at 13:38 -0500, Carl Meyer wrote:
> On 05/16/2014 12:10 PM, Donald Stufft wrote:
> >> 2. Add a deprecation path for --allow-unverified; can describe it in
> >> general terms as "the PEP 438 installer flag allowing installation of
> >> unverified external packages" if you don't
On 05/16/2014 12:10 PM, Donald Stufft wrote:
>> 2. Add a deprecation path for --allow-unverified; can describe it in
>> general terms as "the PEP 438 installer flag allowing installation of
>> unverified external packages" if you don't want to be pip-specific.
>> Currently PEP 470 has no mention of
On 16 May 2014 18:40, Donald Stufft wrote:
> Right, I think maybe we're agreeing? If we're not I'm not sure what the delta
> is between what Carl's saying and what the PEP is (attempting?) to convey.
Yeah, sounds like we're all in agreement. That's the pip team on
board, let's hope the rest of th
On May 16, 2014, at 1:35 PM, Paul Moore wrote:
> On 16 May 2014 18:10, Donald Stufft wrote:
>> We can have a singular
>> clear message that says "If you want to do X then use these flags" and it
>> doesn't matter what version you're on. I vastly prefer that to the current
>> situation (and the
On 16 May 2014 18:10, Donald Stufft wrote:
> We can have a singular
> clear message that says "If you want to do X then use these flags" and it
> doesn't matter what version you're on. I vastly prefer that to the current
> situation (and the "just let the deprecation run it's course" proposal) whe
On May 16, 2014, at 11:38 AM, Carl Meyer wrote:
> Hi Donald and Holger,
>
> Let me try to summarize the core points here to make sure I'm
> understanding correctly:
>
> 1. A transition to allowing only pypi-explicit links (deprecating and
> removing pypi-*-crawl), as already envisioned in PEP
Hi Donald and Holger,
Let me try to summarize the core points here to make sure I'm
understanding correctly:
1. A transition to allowing only pypi-explicit links (deprecating and
removing pypi-*-crawl), as already envisioned in PEP 438, would solve
the worst problem that PEP 470 is trying to solv
On May 16, 2014, at 8:45 AM, holger krekel wrote:
> On Fri, May 16, 2014 at 08:20 -0400, Donald Stufft wrote:
>>
>>
>> Uploading was not vulnerable to heart bleed, but only because uploading
>> doesn’t generally use HTTPS at all yet.
>
> Wait, uploading release files does not use https? I us
On Fri, May 16, 2014 at 08:20 -0400, Donald Stufft wrote:
> On May 16, 2014, at 8:06 AM, holger krekel wrote:
>
> > On Fri, May 16, 2014 at 07:20 -0400, Donald Stufft wrote:
> >> On May 16, 2014, at 6:16 AM, holger krekel wrote:
> >>
> >>> Hi Donald, Nick, Richard, all,
> >>>
> >>> finally got
On May 16, 2014, at 8:06 AM, holger krekel wrote:
> On Fri, May 16, 2014 at 07:20 -0400, Donald Stufft wrote:
>> On May 16, 2014, at 6:16 AM, holger krekel wrote:
>>
>>> Hi Donald, Nick, Richard, all,
>>>
>>> finally got around to read and think about the issues discussed in PEP470.
>>> Fir
On Fri, May 16, 2014 at 07:20 -0400, Donald Stufft wrote:
> On May 16, 2014, at 6:16 AM, holger krekel wrote:
>
> > Hi Donald, Nick, Richard, all,
> >
> > finally got around to read and think about the issues discussed in PEP470.
> > First of all thanks for going through the effort of trying t
On May 16, 2014, at 6:16 AM, holger krekel wrote:
> Hi Donald, Nick, Richard, all,
>
> finally got around to read and think about the issues discussed in PEP470.
> First of all thanks for going through the effort of trying to
> advance the overall situation with a focus on making it easier
>
On 16 May 2014 11:16, holger krekel wrote:
> However, I think PEP470 needs to achieve stronger backward compatibility for
> end-users because, as is typical for the 99%, they like to see change
> but hate to be forced to change themselves.
>
> Allow me to remind of how PEP438 worked in this regard
Hi Donald, Nick, Richard, all,
finally got around to read and think about the issues discussed in PEP470.
First of all thanks for going through the effort of trying to
advance the overall situation with a focus on making it easier
for our wonderful and beloved "end users" :)
However, I think
37 matches
Mail list logo
