On 8 July 2017 at 13:36, Nathaniel Smith wrote:
> On Fri, Jul 7, 2017 at 6:23 AM, Daniel Holth wrote:
>> FYI distutils supports out of tree builds too. It is the -b argument to
>> 'setup.py build'.
>
> In theory, yes, but in practice, there are lots of setup.py files out
> there that mutate the s
On 7 July 2017 at 23:23, Daniel Holth wrote:
> FYI distutils supports out of tree builds too. It is the -b argument to
> 'setup.py build'.
Sort of. That's short for "--bdist-dir" and tells distutils/setuptools
not to use the "dist/" subdirectory for either build trees or the
build artifacts. It d
On Fri, Jul 7, 2017 at 6:23 AM, Daniel Holth wrote:
> FYI distutils supports out of tree builds too. It is the -b argument to
> 'setup.py build'.
In theory, yes, but in practice, there are lots of setup.py files out
there that mutate the source directory. For example, every project
using Cython.
On Fri, Jul 7, 2017 at 4:05 AM, Paul Moore wrote:
> On 7 July 2017 at 11:30, Nathaniel Smith wrote:
>> Is it absolutely necessary to get this into the first PEP?
>
> As far as I'm concerned, it's no more than a restating (and
> simplification?) of all the discussions around building out of tree
>
On 7 July 2017 at 20:30, Nathaniel Smith wrote:
> I think this is a really interesting idea, but it makes me very
> nervous that we're starting design work on novel features when we
> still haven't finalized a basic build_wheel hook.
This isn't a novel feature, it's a revised approach to how we s
On Fri, Jul 7, 2017 at 9:23 AM Daniel Holth wrote:
> FYI distutils supports out of tree builds too. It is the -b argument to
> 'setup.py build'.
>
And it works in bdist_wheel by adding half a dozen lines. It copies the -b
argument to the 'build' subcommand, so effectively you can put the ./build
FYI distutils supports out of tree builds too. It is the -b argument to
'setup.py build'.
On Fri, Jul 7, 2017 at 7:08 AM Paul Moore wrote:
> Also, please note that the proposal doesn't *prohibit* in-place
> builds, quite the opposite, it allows backends to decide when asked
> how to implement bo
Also, please note that the proposal doesn't *prohibit* in-place
builds, quite the opposite, it allows backends to decide when asked
how to implement both in-place and out of place builds (where the
current tree allows backends to decide how to do in place builds and
how to copy trees, and leaves th
On 7 July 2017 at 11:30, Nathaniel Smith wrote:
> Is it absolutely necessary to get this into the first PEP?
As far as I'm concerned, it's no more than a restating (and
simplification?) of all the discussions around building out of tree
via creating an sdist and unpacking it, or having the variou
On Fri, Jul 7, 2017 at 12:59 AM, Thomas Kluyver wrote:
> On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote:
>> On reflection, I'm less concerned about this than I was. If you wanted
>> to propose a stripped down version of PEP 517 which assumed it was the
>> backend's responsibility to ensure rep
On 7 July 2017 at 08:59, Thomas Kluyver wrote:
> On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote:
>> On reflection, I'm less concerned about this than I was. If you wanted
>> to propose a stripped down version of PEP 517 which assumed it was the
>> backend's responsibility to ensure reproducibl
On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote:
> On reflection, I'm less concerned about this than I was. If you wanted
> to propose a stripped down version of PEP 517 which assumed it was the
> backend's responsibility to ensure reproducible isolated builds, I'd
> be willing to listen. But th
12 matches
Mail list logo
