BF: fix bug for Windows bat-file install

[matthew-brett]

Windows .bat file shadow of Python script fails for paths with spaces.

Thanks to P. Renner for the fix - see
matthew-brett/myscripter#2

[larsoner]

LGTM

[matthew-brett]

Thanks - merging.

[yarikoptic]

btw why bother with the custom solution if setuptools have entry points mechanism to generate all the necessary executables? see e.g. datalad or duecredit for an example

[matthew-brett]

First - I was old school in preferring a solution that doesn't have a run-time dependency on setuptools. Second, I find the entry-points mechanism ugly and confusing. Discussion at https://matthew-brett.github.io/pydagogue/installing_scripts.html

[yarikoptic]

On Tue, 11 Aug 2015, Matthew Brett wrote:

First - I was old school in preferring a solution that doesn't have a
run-time dependency on setuptools. Second, I find the entry-points
mechanism ugly and confusing. Discussion at
https://matthew-brett.github.io/pydagogue/installing_scripts.html

;) the only critique I see there is
"... it means we have an install time and a run time dependency on setuptools"
which is imho is ok in this state of the Python ecosystem ;)

"Personally, I find the console_script mechanism more obscure than having script files."

to my liking I found it not that obscure and actually pleasantly
surprised that it works nicely across platforms with me doing
nothing for that to happen ;)

Another positive side-effect is that it requires moving script's
functionality under the library namespace, thus making it easier to
provide unit-tests for that functionality (instead of keeping scripts
outside of the library and having no tests for them, or diving into
another level of sophistication of testing scripts at the "integration"
level, not as unit-tests). E.g. with mocking it becomes really easy to
test basic assumptions of what those scripts should do (what they should
call, see e.g.
https://github.com/duecredit/duecredit/blob/master/duecredit/tests/test_dueswitch.py#L18
although not for cmdline scripts)

Just my 1c

[matthew-brett]

Sure. Of course you can move as much of the scripting into the library as you want with the distutils approach, it's just setuptools forces you to do that. E.g : https://github.com/matthew-brett/wheels2dmg/blob/master/scripts/wheels2dmg

I also find setuptools unpleasantly magical - like an incantation - and that always makes me feel uncomfortable.

[yarikoptic]

On Tue, 11 Aug 2015, Matthew Brett wrote:

Sure. Of course you can move as much of the scripting into the library as
you want with the distutils approach, it's just setuptools forces you to
do that. E.g :
https://github.com/matthew-brett/wheels2dmg/blob/master/scripts/wheels2dmg

yeap... the point though stands that there is then no need for such
custom scripts at all with entry points.

I also find setuptools unpleasantly magical - like an incantation - and
that always makes me feel uncomfortable.

Entire Python is like magic to me -- I just learned how to use it ;)
Seems to work (most of the time ;) )

But I am actually with you on "setuptools magic" -- that is why I was
trying to avoid using it whenever I could, but then seeing many projects
using it (thus polishing up its bugginess) and this entry_points
support made me start using it.

[matthew-brett]

I also heard someone involved in the Python packaging system saying they were planning to make wheels installable without setuptools, implying that they (like me) want to avoid setuptools where possible. That might make it more common in the future to have Python installations without setuptools installed.