Hi folks,
Forwarding this PEP from python-dev, since there's a small piece of it that
falls into distutils-sig's area of responsibility: claiming the "Typing"
key in the distribution metadata to allow projects to state whether or not
they natively provide type annotations.
This seems like a reaso
On 27 October 2017 at 01:45, Thomas Kluyver wrote:
>
>
> On Thu, Oct 26, 2017, at 03:57 PM, Daniel Holth wrote:
>
> Would something as simple as a file per sys.path with the 'last modified
> by installer' date be helpful? You could check those to determine whether
> your cache was out of date.
>
Heads up to anyone running pypiserver, this breaks the default redirection
from pypiserver to PyPI. There's an open issue[1] to fix it. In the
meantime, you can use the pypiserver option `--fallback-url
https://pypi.python.org/simple/` to work around it.
--nate
[1] https://github.com/pypiserver/p
On Thu, Oct 26, 2017, at 03:57 PM, Daniel Holth wrote:
> Would something as simple as a file per sys.path with the 'last
> modified by installer' date be helpful? You could check those to
> determine whether your cache was out of date.
I wonder if we could use the directory mtime for this? It's o
Historically PyPI was only available over either HTTP or unvalidated HTTPS, and
over time we’ve been pushing more and more traffic onto HTTPS. In Warehouse the
decision was made to *not* redirect “API” URLs from HTTP to HTTPS, but to
rather return an error accessing them from HTTP. This is becau
I agree. The "malware" problem is really a "how do I understand which hooks
run in each environment" problem. The hooks could slow down or confuse,
frustrate people in ways that were unrelated to any malicious intent.
The caching could just be a more efficient, lossless representation of the
*.dis
On 26 October 2017 at 18:33, Thomas Kluyver wrote:
> Nathaniel raises the point that it may be easier to convince other package
> managers to regenerate an entry points cache than to call arbitrary Python
> hooks on install.
>
At least for RPM, we have file triggers now, whereby system packages
On Sat, Oct 21, 2017, at 07:59 AM, Nick Coghlan wrote:
> Yeah, here's the gist of what I had in mind regarding the malware
> problem (i.e. aiming to ensure we don't get all of setup.py's problems
> back again):>
> - a package's own install hooks do *not* get called for that package
> - hooks only
On Fri, Oct 20, 2017 at 11:59 PM, Nick Coghlan wrote:
> Yeah, here's the gist of what I had in mind regarding the malware problem
> (i.e. aiming to ensure we don't get all of setup.py's problems back again):
>
> - a package's own install hooks do *not* get called for that package
Doesn't that bre
Am 24.10.2017 um 13:34 schrieb Pradyun Gedam:
There's actually a couple of PEPs written for this
-- PEP 458 and PEP 480. :)
Thank you for the links.
Regards,
Thomas Güttler
--
Thomas Guettler http://www.tho
10 matches
Mail list logo
