[Distutils] Provisionally accepting PEP 517's declarative build system interface

Thomas Kluyver thomas at kluyver.me.uk
Sat Jun 3 06:09:14 EDT 2017


On Sat, Jun 3, 2017, at 10:55 AM, Paul Moore wrote:
> 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.

Another alternative would be to unpack the sdist, carefully modify the
files you want, and tar it back up manually. If this is needed a lot, it
shouldn't be hard to write tools to help with this.

I'm not going to claim this is a perfect system, but I prefer it to
every alternative I've thought of so far. ;-)

> 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?

One thing you could do is to have a subfolder containing the package as
you want it to be in an sdist, including the flit.ini/pyproject.toml
file. When flit makes an sdist, it will only use the folder where that
file is found - so that you can e.g. have multiple packages in one
repository.

More generally, though, I'd question why you don't want those files to
be in an sdist? Why should an sdist be any different to a snapshot of
your VCS at release time, including all of your thoughts and tools used
in development? Installation will usually use a wheel, so download size
shouldn't be a major concern.

I might consider adding an additional way to exclude files from an
sdist, but I'll leave it a while to see if a compelling need emerges
before adding more complexity.

Thomas


More information about the Distutils-SIG mailing list