Re: [Distutils] PEP 517: Build system API

On 29 November 2016 at 21:41, Thomas Kluyver wrote: > On Thu, Nov 24, 2016, at 11:10 PM, Paul Moore wrote: > But even without that, they're not ideal. I routinely have development > installs of quite a lot of different packages. If each one of those is > an entry on sys.path

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016, at 11:10 PM, Paul Moore wrote: > Honestly, I don't see what's so bad about pth files. They are a > standard supported Python approach. Maybe setuptools' use of them is > messy? I recall it was possible to end up with a lot of clutter, but > that was going back to the egg

Re: [Distutils] PEP 517: Build system API

On 29 November 2016 at 07:23, Daniel Holth 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

Re: [Distutils] PEP 517: Build system API

On 29 November 2016 at 04:23, Daniel Holth 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

Re: [Distutils] PEP 517: Build system API

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

Re: [Distutils] PEP 517: Build system API

On Mon, Nov 28, 2016 at 10:01 AM, Paul Moore wrote: > On 28 November 2016 at 17:53, Chris Barker wrote: > >> Why not just have a single pth file, maintained by the build > >> tool, for all editable installs? > > > > shouldn't that be maintained by the

Re: [Distutils] PEP 517: Build system API

On 28 November 2016 at 17:53, Chris Barker wrote: >> Why not just have a single pth file, maintained by the build >> tool, for all editable installs? > > shouldn't that be maintained by the install tool? i.e. pip -- the whole idea > is that the install tool is different

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016 at 3:10 PM, Paul Moore wrote: > Honestly, I don't see what's so bad about pth files. They are a > standard supported Python approach. Maybe setuptools' use of them is > messy? exactly. The fact that setuptools over-uses (abuses?) pth files doesn't

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 4:32 PM, Nathaniel Smith wrote: > On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker > wrote: > > > Please, please, let's figure SOMETHING our here - editable installs (or > > "develop" installs) are a critical tool. Frankly, I don't

Re: [Distutils] PEP 517: Build system API

I suppose a __main__.py could also/instead be added as - site.tools.__main__ https://github.com/python/cpython/blob/master/Lib/site.py - site.__doc__ - site._script() - distutils.__main__ https://github.com/python/cpython/tree/master/Lib/distutils/command - setuptools.__main__

Re: [Distutils] PEP 517: Build system API

On 26 November 2016 at 19:34, Wes Turner wrote: > On Friday, November 25, 2016, Nick Coghlan wrote: >> By contrast, if we only propose deprecating "import" lines in ".pth" >> files, and also propose a more explicit approach to automatic code >> execution

Re: [Distutils] PEP 517: Build system API

On Friday, November 25, 2016, Nick Coghlan wrote: > On 25 November 2016 at 12:26, Robert Collins > wrote: > > On 25 November 2016 at 14:04, Nick Coghlan > wrote: > >> The bad reputation of ".pth"

Re: [Distutils] PEP 517: Build system API

On 25 November 2016 at 12:26, Robert Collins wrote: > On 25 November 2016 at 14:04, Nick Coghlan wrote: >> The bad reputation of ".pth" doesn't generally stem from their normal >> usage (i.e. just listing absolute or relative directory names that

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016, at 07:22 PM, Donald Stufft wrote: > I think at a minimum we should get PEP 518 support into pip first. I > don't think layering more things on top of a PEP that isn't yet > implemented is a good approach to this. I went to make a start on this, but I got stuck on whether

Re: [Distutils] PEP 517: Build system API

actually editable installs can be made uninstallable trivially in gumby-elf i would create a fake wheel with files inside to facilitate the path building for namespaces, and a local version number (so pip would create my exe files and uninstall clean) -- Ronny On 24.11.2016 01:23, Daniel Holth

Re: [Distutils] PEP 517: Build system API

On 25 November 2016 at 14:04, Nick Coghlan wrote: .. > > The bad reputation of ".pth" doesn't generally stem from their normal > usage (i.e. just listing absolute or relative directory names that the > import system will then append to __path__). > > Rather, it stems from this

Re: [Distutils] PEP 517: Build system API

On 25 November 2016 at 09:10, Paul Moore wrote: > Honestly, I don't see what's so bad about pth files. They are a > standard supported Python approach. Maybe setuptools' use of them is > messy? I recall it was possible to end up with a lot of clutter, but > that was going

Re: [Distutils] PEP 517: Build system API

Thomas Kluyver wrote: - There's a feature called NTFS Junction Points, which is supposed to be like symlinks, but only for directories. Things might have changed, but last time I played with junction points they seemed rather dangerous, because if you deleted one using the GUI it deleted the

Re: [Distutils] PEP 517: Build system API

On 24 November 2016 at 21:51, Thomas Kluyver wrote: > On Thu, Nov 24, 2016, at 08:07 PM, Paul Moore wrote: >> Just curious - how does flit handle Windows for this? Symlinks aren't >> really an option there (you need elevation to create a symlink). >> Paul > > It largely

Re: [Distutils] PEP 517: Build system API

I've made PRs against PEP 517 for: Underscore to dash in build-backend: https://github.com/python/peps/pull/139 1a: Add a user parameter to the install_editable hook https://github.com/python/peps/pull/140 OR: 1c: Get rid of the install_editable hook https://github.com/python/peps/pull/141

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016, at 08:07 PM, Paul Moore wrote: > Just curious - how does flit handle Windows for this? Symlinks aren't > really an option there (you need elevation to create a symlink). > Paul It largely doesn't at present; it started out as a personal tool for me, and I mostly use Linux. I

Re: [Distutils] PEP 517: Build system API

On 24 November 2016 at 19:50, Thomas Kluyver wrote: > I hate the thing setuptools does with .pth files all over the place, so the > equivalent operation in flit symlinks packages to site-packages. Just curious - how does flit handle Windows for this? Symlinks aren't really

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016, at 07:50 PM, Thomas Kluyver wrote: > I made a PR to flit to handle this case better in uninstallation. I meant a PR to *pip*. ___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] PEP 517: Build system API

On 24 November 2016 at 00:32, Nathaniel Smith wrote: > Also note that just like we decided to split the basic pyproject.toml > proposal (now PEP 518) from the build system interface proposal (now > PEP 517), it might (probably) makes sense to split the editable > install part of

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker wrote: > On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver > wrote: > >> >> Questions: >> 1. Editable installs. The PEP currenly specifies a hook to do an >> editable install (like 'pip install -e' or

Re: [Distutils] PEP 517: Build system API

I wouldn't be afraid of editable installs. They are trivial and involve building the package in place and putting a .pth file where it will be noticed. Specify editable packages can't necessarily be uninstalled in a standard way and you are done. The bespoke build tool tells pip where the package

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver wrote: > Questions: > 1. Editable installs. The PEP currenly specifies a hook to do an > editable install (like 'pip install -e' or 'setup.py develop') into a > given prefix. I don't think that specifying a prefix is

Re: [Distutils] PEP 517: Build system API

On 23 November 2016 at 19:17, Brett Cannon wrote: > My vote is for 1c (easier to add 1a later), and dashes (for some reason I > just like how they look more in config files). I agree, 1c sounds like a reasonable starting place (but I don't tend to use editable installs, so

Re: [Distutils] PEP 517: Build system API

Hi, On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver wrote: > I'd like to push PEP 517 forwards again. This PEP specifies a general > build system interface so that a source tree can specify a tool (such as > flit), and pip can ask that tool to generate a wheel. This would

Re: [Distutils] PEP 517: Build system API

Thanks for starting this up again! My vote is for 1c (easier to add 1a later), and dashes (for some reason I just like how they look more in config files). On Wed, Nov 23, 2016, 06:36 Thomas Kluyver, wrote: > I'd like to push PEP 517 forwards again. This PEP specifies a

[Distutils] PEP 517: Build system API

I'd like to push PEP 517 forwards again. This PEP specifies a general build system interface so that a source tree can specify a tool (such as flit), and pip can ask that tool to generate a wheel. This would allow us to install from an sdist or a VCS checkout without running a setup.py file.