On 3 June 2017 at 10:45, Thomas Kluyver
One thing that's not clear to me: a crucial use case for sdists is (1) download, (2) unpack, (3) patch the source, possibly adding new files, (4) build and install. (After all, the whole reason we insist on distributing sdists is that open source software should be modifiable by the recipient.) Does flit currently support this, given the reliance on VCS metadata?
Flit does support that, so long as step 4 never needs to build an sdist. Producing the sdist is the only operation for which flit needs the VCS.
This is why I'm doggedly arguing that building and installing should be possible without invoking any 'sdist' hook. ;-)
This is getting very off-topic, but what if I wanted to patch the source and then build a sdist to put into my local PyPI index? I presume the answer is that I either have to checkout the original sources from VCS or I have to build only wheels and maintain my source patches some other way. I can think of realistic reasons why neither of these 2 options are practical, but it is of course your prerogative to not support those cases. Also, I typically have a lot of stuff (working notes, utility scripts, etc) checked into VCS that I don't want to be in the sdist. I don't know if flit has a way to exclude such files - and if it does, why can't it use that method to also allow me to say "exclude everything *except* this list of files" if I want to? This is basically why I'm persistently unable to see why you won't even consider a fallback for building sdists when the VCS isn't present. Paul