[Distutils] PEP 517: Build system API

Paul Moore p.f.moore at gmail.com
Thu Nov 24 18:10:57 EST 2016

On 24 November 2016 at 21:51, Thomas Kluyver <thomas at kluyver.me.uk> 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 doesn't at present; it started out as a personal tool for me,
> and I mostly use Linux. I have a few ideas about how to deal with
> Windows, though:
> - There's a feature called NTFS Junction Points, which is supposed to be
> like symlinks, but only for directories. I believe these can be created
> by regular users without elevated permissions. It might be possible to
> use this for packages, albeit not for single file directories.
> - Create a script/tool to give a user the permission bit that allows
> creating symlinks, so users who know what they're doing can enable it.
> Maybe there's some reason it's admin-only by default, though? It's safe
> enough for normal users on Unix, but I don't know how different Windows
> is.

However you do it, it needs elevation, which is going to be a problem.
I don't think symlinks per se are any worse on Windows (apart from the
unfamiliarity aspect, which also applies to junction points, which may
mean tools don't handle them gracefully). But because you can't use
them without elevation/permission fiddling, they simply aren't an
end-user concept on Windows.

> - Run a daemon to watch package folders and reinstall on any changes,
> something like Nathaniel mentioned with 'pip watch'. I probably wouldn't
> do this as part of flit, but I'd be happy to see it as a separate tool.
> As Nathaniel pointed out, this can actually support more stuff than
> setuptools editable installs, or my symlinks, because it can re-run
> build steps.

That sounds like it could also have some issues making it work cleanly
on Windows (would it leave a console window open?).

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 days, I'm not sure if it's like that
any more. Why not just have a single pth file, maintained by the build
tool, for all editable installs? Most users would then only have one
or two pth files.

Anyway, this is OT, and I'm sure you'll come up with something
appropriate as and when the need arises. As I say, I was mostly just


More information about the Distutils-SIG mailing list