Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017 at 10:21 PM, Nick Coghlan wrote: > On 3 June 2017 at 13:38, Donald Stufft wrote: >> However, what I was able to find was what appears to be the original reason >> pip started copying the directory to begin with, >>

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017 at 8:38 PM, Donald Stufft wrote: > > On Jun 2, 2017, at 10:14 PM, Nathaniel Smith wrote: > >> So far my belief is that packages with expensive build processes are >> going to ignore you and implement, ship, document, and recommend the >>

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 3 June 2017 at 13:38, Donald Stufft wrote: > However, what I was able to find was what appears to be the original reason > pip started copying the directory to begin with, > https://github.com/pypa/pip/issues/178 which was caused by the build system > reusing the build

Re: [Distutils] Malicious packages on PyPI

On 3 June 2017 at 03:43, Donald Stufft wrote: > That would get us to the point we can start collecting data and storing it. > The next step would be to start processing that data to implement a black > list, which would require work to be done in both Warehouse and legacy PyPI.

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017 at 3:58 PM, Thomas Kluyver wrote: > On Fri, Jun 2, 2017, at 06:14 PM, Donald Stufft wrote: > > The steps here would basically be (for building from something that isn’t > already a .tar.gz or a .whl): > > > That sounds OK to me. I think the only

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 2, 2017, at 10:14 PM, Nathaniel Smith wrote: > > On Fri, Jun 2, 2017 at 9:39 AM, Paul Moore wrote: >> Note that there's an implication here - if we define the build process >> in terms of the effect of "going via a sdist", then we need to at >>

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017 at 9:39 AM, Paul Moore wrote: > Note that there's an implication here - if we define the build process > in terms of the effect of "going via a sdist", then we need to at > least have an intuitive understanding of what that means in practice. > I don't

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 06:14 PM, Donald Stufft wrote: > The steps here would basically be (for building from something that > isn’t already a .tar.gz or a .whl): That sounds OK to me. I think the only remaining point of contention is whether the build_sdist hook should make an archive or an

Re: [Distutils] Malicious packages on PyPI

> On Jun 2, 2017, at 12:04 AM, Nick Timkovich wrote: > > I suggested on one of those issues to try to auto-blacklist common 404s as > that should pose a negligible usability hit. I'd like to start by logging > them to collect data, but I'm confused nowadays as to if

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 2, 2017, at 12:39 PM, Paul Moore wrote: > >> >> * The copy_the_files hook is optional, if it exists it SHOULD produce a tree >> that when the build_wheel hook is called in it, will produce a wheel that is >> equivalent to one that would have been built had the

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 3 June 2017 at 02:50, Thomas Kluyver wrote: > On Fri, Jun 2, 2017, at 05:26 PM, Nick Coghlan wrote: >> Could you provide a little more detail as to what you would do >> differently in exporting the contents of an sdist that wouldn't apply >> to export a build tree? (aside

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 18:02, Donald Stufft wrote: > > I’m pretty sure the only reason we don’t do it now is because nobody has had > the time to make it happen yet. The problems before weren’t from going via > sdist, they were from trying to modify our copy tree implementation to >

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 2, 2017, at 12:39 PM, Paul Moore wrote: > > On 2 June 2017 at 16:27, Donald Stufft > wrote: >> So my preference is that everything goes through the sdist step as I think >> that is most likely to provide consistent

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 05:26 PM, Nick Coghlan wrote: > Could you provide a little more detail as to what you would do > differently in exporting the contents of an sdist that wouldn't apply > to export a build tree? (aside from skipping emitting PKG-INFO) When creating an sdist, I query the VCS

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 16:27, Donald Stufft wrote: > So my preference is that everything goes through the sdist step as I think > that is most likely to provide consistent builds everywhere both from a VCS > checkout and from a sdist that was released to PyPI. Agreed. That's the

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

[Note: I've reverted the PEP to Draft status while this discussion is ongoing: https://github.com/python/peps/blob/master/pep-0517.txt] On 3 June 2017 at 00:56, Thomas Kluyver wrote: > On Fri, Jun 2, 2017, at 03:41 PM, Nick Coghlan wrote: >> Instead, the flow that I think

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2017-06-02 15:12:19 +0100 (+0100), Paul Moore wrote: [...] > I'm struggling to understand why building a sdist in flit should need > a VCS. It bothers me that I'm missing something important about how > backends will work, that explains why (for example) you can't create a > sdist from an

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 2, 2017, at 10:41 AM, Nick Coghlan wrote: > > On 2 June 2017 at 23:42, Thomas Kluyver wrote: >> As was suggested at some point, I have added a build_sdist hook to my >> PR, with the following details: >> >> - A brief definition of the minimal

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 03:41 PM, Nick Coghlan wrote: > Instead, the flow that I think makes sense is "VCS -> sdist tree [-> > sdist tree -> sdist tree -> ...] -> wheel", and the above model where > the export filtering is only used when PKG-INFO doesn't exist yet will > give us that. I still

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 23:42, Thomas Kluyver wrote: > As was suggested at some point, I have added a build_sdist hook to my > PR, with the following details: > > - A brief definition of the minimal requirements of an sdist. > - I have limited the definition to gzipped tarballs.

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Fri, Jun 2, 2017, at 03:12 PM, Paul Moore wrote: > I'm struggling to understand why building a sdist in flit should need > a VCS. It bothers me that I'm missing something important about how > backends will work, that explains why (for example) you can't create a > sdist from an export of a VCS

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 14:42, Thomas Kluyver wrote: > - Backends (like flit) where building an sdist has extra requirements > should define prepare_build_files. I'm struggling to understand why building a sdist in flit should need a VCS. It bothers me that I'm missing something

Re: [Distutils] Malicious packages on PyPI

For a first few passes, if the 404-blacklist is sufficiently lax (strict?), only *extremely* common mistypes like "isx" or "requjests" should be caught. The slow response time would then be good as it would force users to think long and hard about if they really want such strange names and/or make

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

As was suggested at some point, I have added a build_sdist hook to my PR, with the following details: - A brief definition of the minimal requirements of an sdist. - I have limited the definition to gzipped tarballs. Zip files also work as sdists, but we're moving towards standardising on

Re: [Distutils] Malicious packages on PyPI

On 2 June 2017 at 19:42, Richard Jones wrote: > On 2 June 2017 at 18:05, Nick Coghlan wrote: >> >> On 2 June 2017 at 09:00, Nick Timkovich wrote: >> > This issue was also brought up in January at >> >

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 18:37, Paul Moore wrote: > On 2 June 2017 at 08:49, Nick Coghlan wrote: >> The last point means that requiring an sdist export command shouldn't >> impose an unreasonable burden on backend developers, as the only >> differences between

Re: [Distutils] Malicious packages on PyPI

On Thursday, June 1, 2017, Matt Joyce wrote: > Force packages to match their higher level import namespace in future > major Python versions and PEP it. > __import__('siht'[::-1]) Though static analysis would still be great. > > On Jun 1, 2017 7:37 PM, "Noah

Re: [Distutils] Malicious packages on PyPI

On 2 June 2017 at 18:05, Nick Coghlan wrote: > On 2 June 2017 at 09:00, Nick Timkovich wrote: > > This issue was also brought up in January at > > https://github.com/pypa/pypi-legacy/issues/585 then just as after the > > initial "typosquatting PyPI"

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 08:49, Nick Coghlan wrote: > The last point means that requiring an sdist export command shouldn't > impose an unreasonable burden on backend developers, as the only > differences between "generate an sdist tree" and "export a build tree" > would be: > > -

Re: [Distutils] Malicious packages on PyPI

On 2 June 2017 at 09:00, Nick Timkovich wrote: > This issue was also brought up in January at > https://github.com/pypa/pypi-legacy/issues/585 then just as after the > initial "typosquatting PyPI" report (June 2016) it's met with resounding > silence. Attacking the

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2 June 2017 at 06:45, Brett Cannon wrote: > And so I think in a very wordy way, I just said we need to stop saying "pip > needs a standardized way to produce an sdist" and instead start saying > "twine needs a way to produce an sdist". And that leads to the question > about