> This would break standard behaviour of distutils. If you have a look at
> the distutils build_scripts.copy_scripts() in the standard library[1]
> you will see that the scripts kwarg is referenced. If possible I think
> we should stick as close as possible to how the standard library does
> things while we are using distutils.

Yes, but we already provide our own copy_scripts() function, and
everything else (including setuptools) should use get_source_files()
API.

https://github.com/python/cpython/pull/27/files

Also the standard behaviour of distutils is already broken, because of
module names instead of paths in `scripts`, which is also the reason
why "develop" command failed.

> As mentioned, there is no urgent need to support 'python setup.py
> develop' in the release (it a feature for developers), so I would
> suggest just reverting hg4963:cdfb1a3fb56f instead of trying to land
> some last minutes changes to setup.py that run the risk of introducing
> new bugs just before a release... especially if migrating to setuptools
> might end up making any new changes redundant anyway.

I want "develop" thing to go into this release, maybe without
generated scripts, because I myself felt a great urge to add
livereload to demo.py while debugging Roundup Jinja2 issue.

I am trying to reduce the risk to minimum. At least I am following
distutils code to see that I broke anything.

Migrating to setuptools will likely to break those old CentOS installs
with ancient Python versions and pip versions, so if needed I would
do this only on major release.

I am not going to abandon this, so release is imminent, just need
to solve this one without creating more technical debt than it is
already there in this issue.

By the way, one way to reduce that debt would be to document distutils
`build_scripts` behaviour - what is expected input, output, and when it
is expected to be called.