On Mon, Jul 17, 2017 at 10:15 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 17 July 2017 at 20:00, Ralf Gommers <ralf.gommers@gmail.com> wrote:
>
>
> On Mon, Jul 17, 2017 at 8:53 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>> On 17 July 2017 at 18:29, Ralf Gommers <ralf.gommers@gmail.com> wrote:
>> > On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan <ncoghlan@gmail.com>
>> > wrote:
>> >> The minimal specification for in-place builds is "Whatever you would
>> >> do to build a wheel file from an unpacked sdist".
>> >
>> > Eh no, in-place has nothing to do with building a wheel. Several people
>> > have
>> > already pointed this out, you're mixing unrelated concepts and that's
>> > likely
>> > due to you using a definition for in-place/out-of-place that's
>> > nonstandard.
>>
>> I'm using in-place specifically to mean any given PEP 517 backend's
>> equivalent of an unqualified "./setup.py build_wheel".
>
>
> Thanks. Very much nonstandard and possibly circular, but at least you've
> defined it:) I suggest you pick more precise wording, because this leaves
> little room for the more common use of in-place. Which you can define in
> several flavors as well, but all of them definitely have the property that
> if you put the source directory on sys.path you can import and use the
> package.  build_wheel does not have that property.

Ah, thanks for clarifying. That's using "in-place" to refer to the
Python-specific notion of an editable install ('setup.py develop',
'pip install -e', etc).

Not really Python-specific, here's two of the first results of a Google search:
https://cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees
https://stackoverflow.com/questions/4018869/what-is-the-in-place-out-of-place-builds
It's basically: build artifacts go right next to the source files. For Python it then follows that you can import from the source dir, but that's just a consequence and not part of the definition of in-place at all.
 
Not a usage I've personally encountered, but
I'm also a former embedded systems developer that now works for an
operating system company, so I'm not necessarily the most up to speed
on common terminology in environments more specifically focused on
Python itself, rather than the full C/C++(/Rust/Go)/Python stack :)

The in-place/out-of-tree sense currently used in the PEP (and my posts
to the list about this point) is the common meaning for compiled
languages, and hence the one common to most full-fledged build
systems.

Well, you keep on saying "build_wheel". A wheel is a packaging artifact rather than a build artifact, and is Python-specific. So not common for compiled languages.
 
My mental picture is:
1. build steps (in/out-place) produce .o, .so, etc. files
2. building a wheel is a two-step process: first there's a build step (see point 1), then a packaging step producing a .whl archive.

I suspect most people will see it like that. Hence it is super confusing to see you describing a *build* concept like in-place with reference to a *packaging* command like build_wheel.

Cheers,
Ralf


However, it will definitely make sense to clarify that point, as it's
quite reasonable for folks to read a phrase with a Python specific
meaning in a PEP, even if key parts of that PEP are primarily about
effectively interfacing with build systems originally designed to
handle precompiled languages :)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia