[Python-Dev] Servicing pypi.python.org

[Facundo Batista]

Hola!

tl;dr: can we have a (semi)permanent redirect from pypi.python.org to pypi.org?

I own/maintain a project called `fades`, which is an automatic
virtualenv creator/manager [0].

While it relies on `pip` itself for the heavy work on the virtualenv
itself, `fades` checks if all required dependencies can be served [1]
*before* starting to do the rest of the work, which saves a lot of
time.

I just noticed that this is broken, because `pypi.python.org` is dead,
and the service should be queried under `pypi.org` directly.

We probably should have switched to the new domain months ago, but you
know how it's open source, it frequently happens that one has to live
first and that leaves no time for fun work.

So, can we have a (semi)permanent redirect from pypi.python.org to pypi.org?

This will help `fades` directly (even if we fix this and release soon,
there will be a lot of older fades in the wild hitting the de[recated
URL) and probably other projects using the old URL.

I suspect that having a generic redirect will not be burdensome server side.

Can we? Can we? P-p-please??? :)

Thanks in advance.

[0] fades.readthedocs.io
[1] using URLs like `https://pypi.python.org/pypi/Twisted/json`

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org.ar/
Twitter: @facundobatista
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Servicing pypi.python.org

[Terry Reedy]

On 10/17/2018 8:32 PM, Facundo Batista wrote:

Hola!

tl;dr: can we have a (semi)permanent redirect from pypi.python.org to pypi.org?


pypi is run by a different group from pydev core developers.
Maybe someone here know what the current list is.

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Servicing pypi.python.org

[Donald Stufft]

> On Oct 17, 2018, at 8:32 PM, Facundo Batista  wrote:
> 
> tl;dr: can we have a (semi)permanent redirect from pypi.python.org 
>  to pypi.org ?


This already exists:

$ curl -I https://pypi.python.org/project/Twisted/json
HTTP/2 301
server: Varnish
retry-after: 0
location: https://pypi.org/project/Twisted/json
content-type: text/html; charset=UTF-8
accept-ranges: bytes
date: Thu, 18 Oct 2018 03:06:12 GMT
x-served-by: cache-iad2626-IAD
x-cache: HIT
x-cache-hits: 0
x-timer: S1539831972.243137,VS0,VE0
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-permitted-cross-domain-policies: none
content-length: 122


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34837: Multiprocessing.Pool API Extension - Pass Data to Workers w/o Globals

[Michael Selik]

If imap_unordered is currently re-pickling and sending func each time it's
called on the worker, I have to suspect there was some reason to do that
and not cache it after the first call. Rather than assuming that's an
opportunity for an optimization, I'd want to be certain it won't have edge
case negative effects.


On Tue, Oct 16, 2018 at 2:53 PM Sean Harrington 
wrote:

> Is your concern something like the following?
>
> with Pool(8) as p:
> gen = p.imap_unordered(func, ls)
> first_elem = next(gen)
> p.apply_async(long_func, x)
> remaining_elems = [elem for elem in gen]
>

My concern was passing the same function (or a function with the same
qualname). You're suggesting caching functions and identifying them by
qualname to avoid re-pickling a large stateful object that's shoved into
the function's defaults or closure. Is that a correct summary?

If so, how would the function cache distinguish between two functions with
the same name? Would it need to examine the defaults and closure as well?
If so, that means it's pickling the second one anyway, so there's no
efficiency gain.

In [1]: def foo(a):
   ...: def bar():
   ...: print(a)
   ...: return bar
In [2]: f = foo(1)
In [3]: g = foo(2)
In [4]: f
Out[4]: .bar()>
In [5]: g
Out[5]: .bar()>

If we say pool.apply_async(f) and pool.apply_async(g), would you want the
latter one to avoid serialization, letting the worker make a second call
with the first function object?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Servicing pypi.python.org

[Benedikt Werner]

This already exists:

$ curl -I https://pypi.python.org/project/Twisted/json
HTTP/2 301
server: Varnish
retry-after: 0
location: https://pypi.org/project/Twisted/json
content-type: text/html; charset=UTF-8
accept-ranges: bytes
date: Thu, 18 Oct 2018 03:06:12 GMT
x-served-by: cache-iad2626-IAD
x-cache: HIT
x-cache-hits: 0
x-timer: S1539831972.243137,VS0,VE0
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-permitted-cross-domain-policies: none
content-length: 122
Especially if you use a project that actually exists like 
https://pypi.python.org/pypi/numpy ;)

Then you don't get a 404 after the redirect which probably was your problem.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com