When using the Windows installer, the .BAT files under 
Scripts directory do not have the correct python path 
and they also lack CRLF termited lines.

Logged In: YES 
user_id=8719

python executable path "python" is correct provided that you
have python on your search path.  it is the best guess for
"one size fits all" installer.  you may build your own
installer by running 'python setup.py bdist_wininst' on your
windows system - it will have the paths adjusted for your
system.

i am not aware of any way to alter the scripts by python
installer stub.  are you?

yes, batch files have unix format newlines because they are
built on unix-like system.  what's the problem?  they run
perfectly well on windows, at least on windows nt line.

Logged In: YES 
user_id=112690

Oh my... Let's see....
I didn't know the way roundup builds the windows installer nor 
if it is or it is not possible to run a python script at the end of 
the process.
I reported this (by emailing to the list) because I found that 
the bat files differs between the installer and 'python setup.py 
install'. Then, Richard asked me to submit a bug report. As 
for me, I wouldn't mind to make this a feature request instead.

Is at least possible to open a message box (or a readme) at 
the end of the install process and tell the user she might has 
to customize the scripts?

Logged In: YES 
user_id=8719

i'm affraid not.  but i am not sure, on the level.

on the other hand, newline issue is fixable if it is really
needed.

Logged In: YES 
user_id=805804

sys.executable could be used; it points to the installed
python.exe. This would make the .bat files work.

In a standard Python installation on Windows, the PATH is
not set to contain the directory containing it; it doesn't
need to, since the interpreter will be called when the name
of a Python file is entered. It would be more useful to put
the ...\Python\Scripts directory in the path, I think.

If '.py' is contained in the PATHEXT environment variable,
even the extension .py can be omitted.

I don't think the newlines are an issue; all editors I use
work perfectly well with *IX or DOS files (at least when the
linebreaks are consistent).

Logged In: YES 
user_id=8719

i do not understand how sys.executable can be used in binary
windows installer to adjust the path in scripts.

Logged In: YES 
user_id=805804

Well, I don't know much about how the binary installer
works, but...

1st: shouldn't it be possible to involke a Python script
which in turn would be able to use sys.executable? Python
must be installed anyway.

2nd possibility (probably the best; works for me): in the
.bat files, rely on the Windows feature which automatically
calls the interpreter for .py files, and possibly use 'if
errorlevel ...' to display an error message with
instructions for the user to insert the full path to the
interpreter himself.

3rd possibility: omit the .bat files, and instruct users to
add .py to the PATHEXT environment variable (which might be
difficult for those who don't have administration rights on
their machine), or let the installer apply this change

4th possibility: a binary installer should be able to query
the registry for the location of the interpreter. I just
seeked for python.exe myself and found:

[HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command]
@="\"C:\\Programme\\Python\\Python24\\python.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open\command]
@="\"C:\\Programme\\Python\\Python24\\python.exe\" \"%1\" %*"
[HKEY_CLASSES_ROOT\Python.File\shell\open\command]
@="\"C:\\Programme\\Python\\Python24\\python.exe\" \"%1\" %*"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\OpenWithList]
"a"="python.exe"
"MRUList"="cba"
"b"="gvim.exe"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache]
"C:\\Programme\\Python\\Python24\\python.exe"="python"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\python.exe\shell\open\command]
@="\"C:\\Programme\\Python\\Python24\\python.exe\" \"%1\" %*"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\Python.exe]
@="C:\\Programme\\Python\\Python24\\Python.exe"
(...)

The last two might be the most useful, but I'm not sure
whether they'd be present e.g. in an ActiveState
installation as well.

Logged In: YES 
user_id=805804

We're talking about Windows...

Like I stated before, the Python interpreter is normally NOT
found along the PATH there. The Python installer simply
doesn't do this! (most programs are never called from the
command line) On my system (standard python 2.4.2 from
python.org) I can call the interpreter through the PATH only
because I created a python.bat in my tools directory,
calling "C:\Programme\Python\Python24\python.exe %*".

The PATH entry isn't normally needed for scripting languages
on Windows; same for the Rexx interpreter which is still
present on my desktop computer. Windows recognises the
extension and calls the appropriate program. Trying to call
the interpreter explicitly DOESN'T WORK.

The newlines should be fixed for the Windows installer
distribution; I'm sure there is a program which can do the
work. I noticed that notepad.exe still doesn't like Unix
line endings; and an Issue tracker which claims to be easy
to use should take care to not scare off unexperienced users.

I couldn't find .bat nor .cmd files in the CVS tree;
otherwise I would have provided a patch.

Do we still provide a windows installable version of roundup?

Answer to my own quession is yes we do.

It is created on a unix system using:

        python setup.py bdist_wininst --user-access-control force

as part of the release process documented in RELEASE.txt.

According ti:

https://docs.python.org/2.7/distutils/builtdist.html#the-postinstallation-script

there is the possibility to add a postinstall script.

So at the very least it can print to stdout what the user may need
to do to get the windows distribution working.

However I am not able to do the work required since I no longer
have reliable access to a modern windows box.

Alternatively we just don't distribute the binary windows version
anymore.

Suggestions before I close this out as postponed?

The ability to create a window binary distribution is deprecated.
So this ticket is out of date.

bdist_wininst is deprecated since Python 3.8.
https://docs.python.org/3/distutils/builtdist.html

closing.