On 29 November 2016 at 04:23, Daniel Holth <dho...@gmail.com> wrote:
> Here is the design. The build tool provides the install tool with a
> directory, or if you want to get fancy, a list of directories, that should
> be added to PYTHONPATH. The build tool builds into that path. The install
> tool makes sure Python can find it. This will make anyone who uses
> setuptools happy.
>
> So PEP 517 does not need an editable install hook to support editable
> installs. It can just expose the equivalent of setuptools'
> package_dir={'':'src'}, and include a 'build in place' hook, and the feature
> is preserved.
>
> In this way setuptools users can be happy, and only users of build systems
> that can't work this way are waiting for a more complicated design.I think this would also help resolve one of the limitations of PEP 517 as it currently stands, which is the differences between environment-per-build and shared-environment, as the former is what you want for releases, but the latter is often what you want locally (e.g. to regenerate cffi and Cython bindings, or to ensure dependencies and the project itself are importable). "local_build" might be a better name for that than "build_in_place" though, and the suggestion of "Sort out release builds first, tackle local builds in a follow-up PEP" still has merit (since the use cases and trade-offs for the latter case are genuinely different from those for builds that are expected to be published to an index server). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
