On Mon, Jul 17, 2017 at 10:15 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 17 July 2017 at 20:00, Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> >
> >
> > On Mon, Jul 17, 2017 at 8:53 PM, Nick Coghlan <ncogh...@gmail.com>
> wrote:
> >>
> >> On 17 July 2017 at 18:29, Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> >> > On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia
>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
