how sdist generation works in enscons
Here's how sdist generation works in enscons. enscons, a build tool that exists to prototype new Python packaging features, is just a set of tools for SCons that makes it easier to generate wheels and sdists. If targets with certain names exist (sdist, bdist_wheel) then the provide setup.py shim and new PEP 517 wrapper will interoperate with pip. For enscons itself, the sdist build rule looks like sdist = env.SDist(source=FindSourceFiles() + ['PKG-INFO', 'setup.py', 'README.rst', 'CHANGES'])env.Alias('sdist', sdist) Enscons would be able to build its own sdist outside a repository, and it would include the listed files plus everything that is used to build the other targets (the wheel). A different package runs 'hg manifest' in a subprocess to feed to env.SDist(), a natural thing to do in this kind of build system. That one would not be able to build another sdist from an unpacked sdist. Enscons itself doesn't have a way to know whether sdist generation will succeed other than trying to run 'SCons sdist' against the user provided build script.
On 6 July 2017 at 12:19, Daniel Holth <dholth@gmail.com> wrote:
Enscons itself doesn't have a way to know whether sdist generation will succeed other than trying to run 'SCons sdist' against the user provided build script.
Right, so the most `enscons` would be able to do to help prepare the build environment is to depend on `import-scons` (as it already does) If the `sdist` target is then missing, or doesn't work, that's a genuine bug in the way the project using `enscons` has been set up, rather than something an end user attempting to build that project would be expected to deal with themselves. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
Daniel Holth -
Nick Coghlan