On 13 May 2014 01:15, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
The packages distil has problems with are those that do significant things in
setup.py, such as moving files
around in the source tree, generating new source files, subclassing distutils
so you can't see what the
actual
Correct me if I'm wrong, but I've a feeling you once said you'd tested
distil against all the packages on PyPI (which is a mammoth task, so I
could easily be wrong...)
Not fully tested in the sense you mean - that *would* be a mammoth task :-)
However, I have tried to make declarative
On 12 May 2014 15:39, Donald Stufft don...@stufft.io wrote:
On May 12, 2014, at 12:50 AM, Nick Coghlan ncogh...@gmail.com wrote:
There are some more notable names in the unsafe lists, but a few
spot checks on projects like PyGObject, PyGTK, biopython, dbus-python,
django-piston, ipaddr,
On May 12, 2014, at 2:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2014 15:39, Donald Stufft don...@stufft.io wrote:
On May 12, 2014, at 12:50 AM, Nick Coghlan ncogh...@gmail.com wrote:
There are some more notable names in the unsafe lists, but a few
spot checks on projects like
On 09.05.2014 12:16, Paul Moore wrote:
So there's an ongoing debate over pip's behaviour around disallowing
external hosting by default (see thread pip: cdecimal an externally
hosted file and may be unreliable over on python-dev for the latest
round).
It appears that the reason for
On 11.05.2014 16:48, Paul Moore wrote:
On 11 May 2014 13:47, Donald Stufft don...@stufft.io wrote:
https://pypi.python.org/simple/egenix-mx-base/ has verifiable external
links. I'm pretty surprised that Donald hasn't heard of mx-base.
egenix-mx-base does not have verifiable external
If this was apt-get or yum, there would be no concept of hosting apart
from an index and you would have to run a command like
apt-add-repository http://xyz.com; or place a file in /etc/... Then
the extra repository + packages would become available.
On Mon, May 12, 2014 at 8:28 AM, M.-A. Lemburg
On 12 May 2014 13:28, M.-A. Lemburg m...@egenix.com wrote:
So, some questions:
1. Is MAL aware that egenix-mx-base is not verifiably externally
hosted[1], and if so, what is he asking for? Automatic download with
no need for opt-in of unverifiable external downloads? That seems
pretty much
Paul Moore p.f.mo...@gmail.com wrote:
I'm not quite sure how you expect this will work, but it's probably
important that you get involved with the various packaging PEPs. The
only way I can see such a solution working with pip would be if you
have a customised setup.py. As the general trend is
On 12.05.2014 15:58, Paul Moore wrote:
On 12 May 2014 13:28, M.-A. Lemburg m...@egenix.com wrote:
So, some questions:
1. Is MAL aware that egenix-mx-base is not verifiably externally
hosted[1], and if so, what is he asking for? Automatic download with
no need for opt-in of unverifiable
On May 12, 2014, at 3:58 PM, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2014 15:58, Paul Moore wrote:
On 12 May 2014 13:28, M.-A. Lemburg m...@egenix.com wrote:
So, some questions:
1. Is MAL aware that egenix-mx-base is not verifiably externally
hosted[1], and if so, what is he asking
On 12.05.2014 22:31, Donald Stufft wrote:
On May 12, 2014, at 3:58 PM, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2014 15:58, Paul Moore wrote:
On 12 May 2014 13:28, M.-A. Lemburg m...@egenix.com wrote:
So, some questions:
1. Is MAL aware that egenix-mx-base is not verifiably
On May 12, 2014, at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2014 22:31, Donald Stufft wrote:
On May 12, 2014, at 3:58 PM, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2014 15:58, Paul Moore wrote:
On 12 May 2014 13:28, M.-A. Lemburg m...@egenix.com wrote:
So, some
On 12.05.2014 22:37, Donald Stufft wrote:
On May 12, 2014, at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
Binary installs are nice, but they are not the answer to everything
and no matter how much meta data you put into static files,
there will always be cases where that meta data
On May 12, 2014, at 4:50 PM, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2014 22:37, Donald Stufft wrote:
On May 12, 2014, at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
Binary installs are nice, but they are not the answer to everything
and no matter how much meta data you put into
On May 12, 2014, at 4:51 PM, Donald Stufft don...@stufft.io wrote:
On May 12, 2014, at 4:50 PM, M.-A. Lemburg m...@egenix.com wrote:
On 12.05.2014 22:37, Donald Stufft wrote:
On May 12, 2014, at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
Binary installs are nice, but they are not
On 12 May 2014 17:15, Stefan Krah stefan-use...@bytereef.org wrote:
Paul Moore p.f.mo...@gmail.com wrote:
I'm not quite sure how you expect this will work, but it's probably
important that you get involved with the various packaging PEPs. The
only way I can see such a solution working with pip
On 12 May 2014 20:58, M.-A. Lemburg m...@egenix.com wrote:
If it helps convince you that allowing verifiable external
links per default is a good thing for user experience, we will
register the distribution file download URLs with the PyPI
web API.
Personally, I'm on the fence over that one.
On 12 May 2014 21:31, Donald Stufft don...@stufft.io wrote:
This is slightly confusing but pip will always be able to go from an sdist to
an installed system. It'll just build a Wheel first and then install the Wheel
(at least that's the idea). This is a sort of vague idea right now but it's
The setup.py interface makes all this possible, which is why so
many Python packages use it to configure themselves automatically.
Deprecating this interface would make some distributions impossible
to install without manual user intervention and we'd be back to the
Makefile.pre.in days.
On 10 May 2014 22:24, Paul Moore p.f.mo...@gmail.com wrote:
On 10 May 2014 12:57, Nick Coghlan ncogh...@gmail.com wrote:
Actually, I expect folks like Stefan MvL would likely want to be able
to
preserve the current --allow-external behaviour. The change Donald is
suggesting could then
On 11 May 2014 08:38, Nick Coghlan ncogh...@gmail.com wrote:
This confusion can likely be resolved by giving the obvious allow external
name to the behaviour most users will want, and a more obscure name like
allow verifiable external to the specialised behaviour folks like Stefan
MAL rely
On 11 May 2014 17:58, Paul Moore p.f.mo...@gmail.com wrote:
On 11 May 2014 08:38, Nick Coghlan ncogh...@gmail.com wrote:
This confusion can likely be resolved by giving the obvious allow
external
name to the behaviour most users will want, and a more obscure name like
allow verifiable
On May 11, 2014, at 3:58 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 11 May 2014 08:38, Nick Coghlan ncogh...@gmail.com wrote:
This confusion can likely be resolved by giving the obvious allow external
name to the behaviour most users will want, and a more obscure name like
allow verifiable
On May 11, 2014, at 4:50 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 11 May 2014 17:58, Paul Moore p.f.mo...@gmail.com wrote:
On 11 May 2014 08:38, Nick Coghlan ncogh...@gmail.com wrote:
This confusion can likely be resolved by giving the obvious allow
external
name to the
Once PEP 458 is put in place, it may be a good idea to make it so that all
external links are verifiable from a security standpoint. (Verifiable in
this sense means the devel uploaded a public key to PyPI that they used to
sign the project metadata.)
We're hoping that once PEP 458 is
On 11 May 2014 13:47, Donald Stufft don...@stufft.io wrote:
https://pypi.python.org/simple/egenix-mx-base/ has verifiable external
links. I'm pretty surprised that Donald hasn't heard of mx-base.
egenix-mx-base does not have verifiable external links.Verifiable external
links must be both
On 11 May 2014 09:50, Nick Coghlan ncogh...@gmail.com wrote:
Let me be clear: this is *not* a technical decision from my perspective. It
is a relationship management one, specifically in regards to maintaining the
still fragile delegation of authority from python-dev to PyPA.
Nick,
Given that
On 11 May 2014 23:18, Donald Stufft don...@stufft.io wrote:
You’re worried that this change is a (or will at least be perceived as
such) FU to Stefan and MAL, I’m worried that not fixing this is a FU to
*everyone else*.
Keep in mind that I am *agreeing* that allow external at the package
level
On May 11, 2014, at 6:04 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 11 May 2014 23:18, Donald Stufft don...@stufft.io wrote:
You’re worried that this change is a (or will at least be perceived as
such) FU to Stefan and MAL, I’m worried that not fixing this is a FU to
*everyone
On 12 May 2014 08:12, Donald Stufft don...@stufft.io wrote:
On May 11, 2014, at 6:04 PM, Nick Coghlan ncogh...@gmail.com wrote:
So, re-reading that, my preference is for option 3: keeping the global
allow-all-external flag, but renaming it as something like
allow-all-verifiable-external. It's
On May 11, 2014, at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2014 08:12, Donald Stufft don...@stufft.io wrote:
On May 11, 2014, at 6:04 PM, Nick Coghlan ncogh...@gmail.com wrote:
So, re-reading that, my preference is for option 3: keeping the global
allow-all-external
From: Paul Moore p.f.mo...@gmail.com
PS To my knowledge, neither distil nor easy_install implement PEP 438
I haven't done any work to make distil production-ready in any sense, and PEP
438 compliance would be a part of such activity. I've been more focused on the
build/meta-build
On 12 May 2014 09:35, Donald Stufft don...@stufft.io wrote:
On May 11, 2014, at 6:49 PM, Nick Coghlan ncogh...@gmail.com wrote:
Specifically, what I would recommend is:
1. Remove any references to the global flag from other documentation and
error messages - always recommend the use of
On May 11, 2014, at 7:35 PM, Donald Stufft don...@stufft.io wrote:
However before I go further on that I want to dig more into the impact of
these
things. It dawned on me earlier today that the way I was categorizing things
in my earlier number crunching was making it unreasonably hard to
On May 11, 2014, at 10:27 PM, Donald Stufft don...@stufft.io wrote:
On May 11, 2014, at 7:35 PM, Donald Stufft don...@stufft.io wrote:
However before I go further on that I want to dig more into the impact of
these
things. It dawned on me earlier today that the way I was categorizing
On 12 May 2014 12:27, Donald Stufft don...@stufft.io wrote:
On May 11, 2014, at 7:35 PM, Donald Stufft don...@stufft.io wrote:
However before I go further on that I want to dig more into the impact of
these
things. It dawned on me earlier today that the way I was categorizing things
in my
On May 12, 2014, at 12:50 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 May 2014 12:27, Donald Stufft don...@stufft.io wrote:
On May 11, 2014, at 7:35 PM, Donald Stufft don...@stufft.io wrote:
However before I go further on that I want to dig more into the impact of
these
things. It
On 10 May 2014 08:03, Paul Moore p.f.mo...@gmail.com wrote:
On 9 May 2014 22:33, Donald Stufft don...@stufft.io wrote:
On the flip side option (A) allows us to make this much simpler
overall. We
can simply do:
If it's hosted on PyPI:
Trust it.
else if it's not hosted
On 10 May 2014 12:57, Nick Coghlan ncogh...@gmail.com wrote:
Actually, I expect folks like Stefan MvL would likely want to be able to
preserve the current --allow-external behaviour. The change Donald is
suggesting could then just be a matter of renaming the current
--allow-external to
On May 10, 2014, at 8:24 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 10 May 2014 12:57, Nick Coghlan ncogh...@gmail.com wrote:
Actually, I expect folks like Stefan MvL would likely want to be able to
preserve the current --allow-external behaviour. The change Donald is
suggesting could
I’ve made a PR for this https://github.com/pypa/pip/pull/1812
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
So there's an ongoing debate over pip's behaviour around disallowing
external hosting by default (see thread pip: cdecimal an externally
hosted file and may be unreliable over on python-dev for the latest
round).
It appears that the reason for disallowing external hosting (as
opposed to
On May 9, 2014, at 6:16 AM, Paul Moore p.f.mo...@gmail.com wrote:
So there's an ongoing debate over pip's behaviour around disallowing
external hosting by default (see thread pip: cdecimal an externally
hosted file and may be unreliable over on python-dev for the latest
round).
It appears
On 9 May 2014 13:17, Donald Stufft don...@stufft.io wrote:
I replied on python-dev already, but I’m still heavily -1.
Yeah, I have no idea if the discussion will migrate here or not, but I tried :-)
This isn’t actually going to help hardly anyone since almost no packages are
hosted safely
On May 9, 2014, at 8:46 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 9 May 2014 13:17, Donald Stufft don...@stufft.io wrote:
I replied on python-dev already, but I’m still heavily -1.
Yeah, I have no idea if the discussion will migrate here or not, but I tried
:-)
This isn’t actually
On 9 May 2014 14:12, Donald Stufft don...@stufft.io wrote:
I think that you’re conflating any bug report about these two flags with bug
reports about externally hosted things at all.
That may well be true. I find this whole thing confusing (which is
sort of my point, I guess). Don't we get a
On May 9, 2014, at 9:38 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 9 May 2014 14:12, Donald Stufft don...@stufft.io wrote:
I think that you’re conflating any bug report about these two flags with bug
reports about externally hosted things at all.
That may well be true. I find this whole
On 9 May 2014 15:05, Donald Stufft don...@stufft.io wrote:
So originally in order to get pip to consider external hosted files at all
you had to have —allow[-all]-external.
Well, *originally* you needed to do nothing. It was only PEP 438 that
made it necessary to do any of this.
On top of
On May 9, 2014, at 11:26 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 9 May 2014 15:05, Donald Stufft don...@stufft.io wrote:
So originally in order to get pip to consider external hosted files at all
you had to have —allow[-all]-external.
Well, *originally* you needed to do nothing. It
OK, basically I get what you mean now.
On 9 May 2014 16:37, Donald Stufft don...@stufft.io wrote:
You’re unlikely to ever encounter an issue where adding —allow-external
actually helps you, but adding it does make it more likely you’ll be hurt.
Well, it helps me in that I never need to think
On May 9, 2014, at 11:41 AM, Paul Moore p.f.mo...@gmail.com wrote:
OK, basically I get what you mean now.
On 9 May 2014 16:37, Donald Stufft don...@stufft.io wrote:
You’re unlikely to ever encounter an issue where adding —allow-external
actually helps you, but adding it does make it more
On 9 May 2014 16:56, Donald Stufft don...@stufft.io wrote:
Right, but I think a similar win can be had just by folding —allow-external
into —allow-unverifiable and make it —allow-off-pypi (needs a better name,
maybe just keep it as --allow-external?). This would effectively mean that
an end
On Fri, May 9, 2014 at 3:16 AM, Paul Moore p.f.mo...@gmail.com wrote:
So there's an ongoing debate over pip's behaviour around disallowing
external hosting by default (see thread pip: cdecimal an externally
hosted file and may be unreliable over on python-dev for the latest
round).
It
On May 9, 2014, at 1:41 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 9 May 2014 16:56, Donald Stufft don...@stufft.io wrote:
Right, but I think a similar win can be had just by folding —allow-external
into —allow-unverifiable and make it —allow-off-pypi (needs a better name,
maybe just keep
On May 9, 2014, at 5:33 PM, Donald Stufft don...@stufft.io wrote:
If it's hosted on PyPI:
Trust it.
else if it's not hosted on PyPI:
Require a --allow-external-and-unverifiable [*]
Bleh, I forgot to add the footnote here that said this option name is terrible
and is
On 9 May 2014 22:33, Donald Stufft don...@stufft.io wrote:
On the flip side option (A) allows us to make this much simpler overall. We
can simply do:
If it's hosted on PyPI:
Trust it.
else if it's not hosted on PyPI:
Require a --allow-external-and-unverifiable [*]
I have nothing useful to add except to say: this thread is one of the most
courteous and productive series of arguments I have seen!
On Fri, May 9, 2014 at 6:02 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 9 May 2014 22:33, Donald Stufft don...@stufft.io wrote:
On the flip side option (A)
58 matches
Mail list logo
